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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 

The present document is part 2 of a multi-part deliverable covering the IMS NNI Interworking Test Specifications, as 
identified below: 

Part 1 : "Test Purposes for IMS NNI Interworking" ; 

Part 2: "Test Descriptions for IMS NNI Interworking". 
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Scope 



The present document specifies interoperability Test Descriptions (TDs) for IMS NNI interoperability testing for the IP 
Multimedia Call Control Protocol based on Stage 3 Session Initiation Protocol (SIP) and Session Description Protocol 
(SDP) standard, TS 124 229 Release 7 [1]. TDs have been specified on the basis of the Test Purposes (TPs) and Test 
Suite Structure (TSS) presented in TS 124 229 [1]. TP fragments presented in the present document as part of TDs are 
defined using the TPLan notation of ES 202 553 [5]. TDs have been written based on the test specification framework 
described in TS 102 351 [3] and the interoperability testing methodology defined in TS 102 237-1 [4], 
i.e. interoperability testing with a conformance relation. 

For the assessment of IMS core network requirements related to the ISC interface parts of the supplementary services 
HOLD (TS 124 410 [10]), CDIV (TS 124 404 [11]), ACR-CB (TS 124 411 [12]) and OIP/OIR (TS 124 407 [13]) have 
been used. 

The scope of these test descriptions is not to cover all requirements specified in TS 124 229 [1]. TDs have been only 
specified for requirements that are observable at the interface between two IMS core network implementations, i.e. IMS 

NNI. 

NOTE: Requirements pertaining to a UE or an AS implementation or IMS core network requirements that can 
only be observed at the interface between UE and IMS CN are explicitly not within the scope of the 
present document. The latter requirements have been dealt with from a UE and conformance perspective 
inTS 134 229 [6]. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 124 229:" Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Internet Protocol (IP) multimedia call control protocol 
based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 
(3GPP TS 24.229 version 7.2.0 Release 7)". 

[2] ETSI TS 186 011-1 (V2.1.1): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); IMS NNI Interworking Test Specifications; Part 1: Test 
Purposes for IMS NNI Interworking". 
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[3] ETSI TS 102 351: "Methods for Testing and Specification (MTS); Internet Protocol Testing (IPT); 

IPv6 Testing: Methodology and Framework". 

[4] ETSI TS 102 237-1: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON) Release 4; Interoperability test methods and approaches; Part 1: Generic approach to 
interoperability testing". 

[5] ETSI ES 202 553: "Methods for Testing and Specification (MTS); TPLan: A notation for 

expressing Test Purposes". 

[6] ETSI TS 134 229: "Universal Mobile Telecommunications System (UMTS); Internet Protocol (IP) 

multimedia call control protocol based on Session Initiation Protocol (SIP) and Session 
Description Protocol (SDP); Part 1: Protocol conformance specification (3GPP TS 34.229-1 
version 7.0.0 Release 7)". 

[7] ETSI TS 133 203: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); 3G security; Access security for IP-based services 
(3GPP TS 33.203 version 6.10.0 Release 6)". 

[8] IETF RFC 2617: "HTTP Authentication: Basic and Digest Access Authentication". 

[9] IETF RFC 2806: "URLs for Telephone Calls". 

[10] ETSI TS 124 410: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); TISPAN; NGN Signalling Control Protocol; 
Communication HOLD (HOLD) PSTN/ISDN simulation services; Protocol specification 
(3GPP TS 24.410 version 7.0.0 Release 7)". 

[11] ETSI TS 124 404: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); TISPAN; PSTN/ISDN simulation services: 
Communication Diversion (CDIV); Protocol specification (3GPP TS 24.404 version 7.0.0 
Release 7)". 

[12] ETSI TS 124 411: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); TISPAN; PSTN/ISDN simulation services: Anonymous 
Communication Rejection (ACR) and Communication Barring (CB); Protocol specification 
(3GPP TS 24.411 version 7.0.0 Release 7)". 

[13] ETSI TS 124 407: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); TISPAN; PSTN/ISDN simulation services; Originating 
Identification Presentation (OIP) and Originating Identification Restriction (OIR); Protocol 
specification (3GPP TS 24.407 version 7.0.0 Release 7)". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 133 978: "Universal Mobile Telecommunications System (UMTS); Security aspects of 

early IP Multimedia Subsystem (IMS) (3GPP TR 33.978 version 6.6.0 Release 6)". 

[i.2] ETSI TR 123 981: "Universal Mobile Telecommunications System (UMTS); Interworking aspects 

and migration scenarios for IPv4-based IP Multimedia Subsystem (IMS) implementations 
(3GPP TR 23.981 version 6.4.0 Release 6)". 
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Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

3 GPP 3^*^ Generation Partnership Project 

ACR Anonymous Communication Rejection 

AKA Authentication and Key Agreement 

AS (IMS) AppHcation Server 

CB Call Barring 

CDIV Call Diversion 

CF (Test) Configuration 

CFW Call Flow 

CN Core Network 

CSCF Call Session Control Function 

DHCP Dynamic Host Configuration Protocol 

DNS Domain Name System 

HOLD Communication HOLD 

HSS Home Subscriber Server 

IBCF Interconnection Border Control Gateway 

I-CSCF Interrogating CSCF 

IMS IP Multimedia Subsystem 

lOI Inter Operator Identifier 

IP Internet Protocol 

IPsec Internet Protocol Security 

ISC IMS Service Control 

NNI Network-to-Network Interface 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

PCO Point of Control and Observation 

P-CSCF Proxy CSCF 

PO Point of Observation 

PSTN PubHc Switched Telephone Network 

SA Security Association 

S-CSCF Serving CSCF 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

SUT System Under Test 

TCP Transmission Control Protocol 

TD Test Description 

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking 

TP Test Purpose 

TPLan Test Purpose Notation 

TSS Test Suite Structure 

UC Use Case 

UE User Equipment 

URI Uniform Record Identifier 

VoIP Voice over Internet Protocol 

XML extensible Markup Language 



IIVIS NNI Interoperability Test Specification 



4.1 



Introduction 



The IMS NNI Interoperability Test Descriptions (TDs) defined in the following clauses are derived from the Test 
Purposes (TPs) specified in TS 186 011-1 [2]. The TDs cover both basic call procedures such as call establishment and 
call release and a selection of the most common supplementary services. 
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4.2 Test Prerequisites 



4.2.1 



IP Version 



These test specifications are based on the use of IPv4 for SIP message transport throughout all IMS nodes as specified 
in TR 123 981 [i.2]. 

4.2.2 Authentication and Security 

The current test specification supports as default full IMS TS 133 203 [7] 3GPP security. Non-compliance with full 
IMS security features defined in TS 133 203 [7] is expected to be a problem mainly at the UE side, because of the 
potential lack of support of the USIM/ISIM interface (especially in 2G-only devices) and of the potential inability to 
support IPsec on some UE platforms. For those reasons, fallback to early IMS TR 133 978 [i.l] and SIP Digest 
authentication without key agreement and null authentication may be used to achieve satisfactory test results. Tests 
should however be executed with full IMS security if all required IMS nodes support it. 

4.2.3 Registration and Subscription 
4.2.3.1 SIP Call Flow 

This clause describes the registration call flow under the authentication and security scope described in clause 4.2.2. 



4.2.3.1.1 



Early IMS Registration and Subscription Call Flow 



Early IMS security does not allow SIP requests to be protected using an IPsec Security Association (SA) because it does 
not perform a key agreement procedure. IPsec security associations are not set up between UE and P-CSCF, as they are 
in the full IMS security solution. For early IMS security, the expected registration and subscription sequence is: 



Step 


Direction 


IVIessage 


Comment 




UE IIVIS 




1 






The UE establishes an IP bearer as required by its 
specific access network (optional). 




2 


^^ 




P-CSCF address discovery using DHCP procedures for 
IPv4 (optional). 




3 


^ 


REGISTER 


The UE sends initial registration for IMS services. 


1 
o 

Q. 

C 

Z) 


4 


^ 


200 OK 


The IMS responds with 200 OK. 


5 


^ 


SUBSCRIBE 


The UE subscribes to its registration event package. 


6 


^ 


200 OK 


The IMS responds with 200 OK. 


7 


^ 


NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state information for 
the registered public user identity in the XML body. 


8 


^ 


200 OK 


The UE responds with 200 OK. 
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4.2.3.1 .2 Full IMS Registration and Subscription Call Flow 

For full IMS security, the expected registration and subscription sequence is: 



Step 


Direction 


IVIessage 


Comment 




UE 1 IIVIS 




1 






The UE establishes an IP bearer as required by its 
specific access network (optional). 




2 


^^ 




P-CSCF address discovery using DHCP 
procedures for IPv4 (optional). 




3 


^ 


REGISTER 


The UE sends initial registration for IMS services. 


"D 
Q) 
O 
Q) 

O 

Q- 

C 
=) 


4 


^ 


401 Unauthorized 


The IMS responds with a valid Digest AKA 
authentication challenge and a list of integrity and 
encryption algorithms supported by the network as 
defined in the IMS AKA procedure of 
TS 133 203 [7]. 


5 






Upon receipt of 401 Unauthorized, the UE selects 
the first integrity and encryption algorithm 
combination on the list received from the P-CSCF in 
401 Unauthorized which is also supported by the 
UE. If the P-CSCF did not include any 
confidentiality algorithm in 401 Unauthorized then 
the UE shall select the NULL encryption algorithm. 
The UE then proceeds to establish two new pairs of 
IPSEC security associations (SA1 and SA2). 




6 


^ 


REGISTER 


The UE sends another REGISTER with 
authentication credentials over IPSEC security 
association SA1 . 


"D 
- < 

o > 


7 


^ 


200 OK 


The IMS responds with 200 OK over the same 
IPSEC security association SA1 . 


8 


^ 


SUBSCRIBE 


The UE subscribes to its registration event package 
over the IPSEC security association SA2. 


< 

CO 

"D 
CD 

O 
CD 

O 


9 


^ 


200 OK 


The IMS responds with 200 OK over the IPSEC 
security association SA2. 


10 


^ 


NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body, over the IPSEC security association 
SA2. 


11 


^ 


200 OK 


The UE responds with 200 OK over the IPSEC 
security association SA2. 
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4.2.3.1.3 



SIP Digest Registration and Subscription Call Flow 



For SIP Digest authentication without key agreement and null authentication, the expected registration and subscription 
sequence is: 



Step 


Direction 


IVIessage 


Comment 




UE 1 IIVIS 




1 






The UE establishes an IP bearer as required by its 
specific access network (optional). 




2 


^^ 




P-CSCF address discovery using DHCP 
procedures for IPv4 (optional). 




3 


^ 


REGISTER 


The UE sends initial registration for IMS services. 


"D 
CD 

1 

O 
Q- 

c 
Z) 


4 


^ 


401 Unauthorized 


The IMS responds with a valid HTTP Digest 
authentication challenge as defined in 
RFC 2617 [8]. 


5 


^ 


REGISTER 


The UE sends another REGISTER with 
authentication credentials. 


6 


^ 


200 OK 


The IMS responds with 200 OK. 


7 


^ 


SUBSCRIBE 


The UE subscribes to its registration event 
package. 


8 


^ 


200 OK 


The IMS responds with 200 OK. 


9 


^ 


NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body. 


10 


^ 


200 OK 


The UE responds with 200 OK. 



4.2.4 Supported Options 



4.2.4.1 



Security 



Support for security agreement is optional in case of Full IMS Reg. It shall only be used in case all IMS nodes support 
it. 



4.2.4.2 



Signalling Connpression 



"No SigComp" is the default signalling configuration in all test descriptions. Tests may be executed with signalling 
compression if the required nodes support it. 



4.3 



Test Infrastructure 



In these clauses we define the involvement of the various IMS nodes specifically as they pertain to NNI testing. The 
configuration of the nodes is described. Points of control and observation are identified and static test configurations are 
described. The Mw interface or the Ic interface if topology hiding is required is the interface under observation for NNI 
interoperability testing. 

4.3.1 Core IMS Nodes 

Because the current testing scope excludes IMS roaming and border control functionality, P-CSCF, S-CSCF, I-CSCF, 
IBCF and HSS are considered to be within a "black box" for testing purposes, i.e. the System Under Test (SUT). 
Interfaces within the IMS are considered internal and not observable for testing purposes. 
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4.3.1.1 P-CSCF 

4.3.1 .1.1 Relevant Interfaces 

The P-CSCF constitutes the point of entry for UE signalling into the IMS core. The Gm interface between the P-CSCF 
and the UE is used as a Point of Control and Observation (PCO) for NNI interoperability testing purposes. In the case of 
IMS roaming configurations where no topology hiding is applied the Mw interface of the P-CSCF is exposed at the NNI 
and used there as a Point of Observation (PO). 

4.3.1 .1 .2 Node Configuration 

The P-CSCF should be configured to support the pre-requisites outlined in clause 4.2. 

4.3.1.2 S-CSCF 

4.3.1 .2.1 Relevant Interfaces 

The S-CSCF is the core IMS node delivering IMS services to subscribers. When no topology hiding is applied, the Mw 
interface between the S-CSCF and either I- or S-CSCF in another network domain is used as a PO against which NNI 
interoperability tests are validated. The Mw interfaces between I- and S-CSCFs within the same network are considered 
to be internal IMS interfaces. Although considered as internal and not explicitly involved in all NNI test configurations, 
it is recommended that these interface are exposed for troubleshooting purposes. 

4.3.1 .2.2 Node Configuration 

The S-CSCF should be configured to support the pre-requisites outlined in clause 4.2. When applicable based on the 
specific configuration, the S-CSCF must be provisioned to support required application servers (AS) as trusted nodes. 

4.3.1.3 l-GSCF 

4.3.1 .3.1 Relevant Interfaces 

The I-CSCF is the contact point within an operator's network for all connections destined to a user of that network 
operator or a roaming user currently located within that network operator's service area. When no topology hiding is 
applied, the Mw interface between the I-CSCF and an S-CSCF in another network domain is used as a PO against 
which NNI interoperability tests are validated. The Mw interfaces between I- and S-CSCFs within the same network are 
considered to be internal IMS interfaces. Although considered as internal and not explicitly involved in all NNI test 
configurations, it is recommended that these interface are exposed for troubleshooting purposes. 

4.3.1 .3.2 Node Configuration 

The I-CSCF should be configured to support the pre-requisites outlined in clause 4.2. 

4.3.1.4 IBGF 

The IBCF is the core IMS node providing topology hiding. When topology hiding is applied, the Ic interface between 
the IBCF and either IBCF or I- or S-CSCF in another network domain is used as a PO against which NNI 
interoperability tests are validated. The Mw interfaces between IBCF and I- or S-CSCFs within the same network are 
considered to be internal IMS interfaces. Although considered as internal and not explicitly involved in all NNI test 
configurations, it is recommended that these interfaces are exposed for troubleshooting purposes. 

4.3.1 .4.1 Node Configuration 

The IBCF should be configured to support the pre-requisites outlined in clause 4.2. The need to activate the IBCF as 
part of an IMS core network depends highly on the test description to be executed. In case the requirement to support 
topology hiding is not explicitly stated in the pre-conditions of a test description it shall be assumed that the IBCF is not 
activated. 
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4.3.1.4.2 



Relevant Interfaces 



4.3.1.5 



HSS 



4.3.1.5.1 



Relevant Interfaces 



The HSS constitutes the repository for IMS subscriber information. The Cx interface between the HSS and the S-CSCF 
and/or I-CSCF is considered an internal IMS interface. 



4.3.1.5.2 



Node Configuration 



The HSS should be configured within each IMS participating in an interoperability test, i.e. IMS_A as well as IMS_B, 
to interact with CSCFs as required using DIAMETER Cx interfaces. Users should be provisioned to match the sample 
profiles listed in table 1 . In addition, each IMS shall have its own unique domain. Also the phone numbers configured in 
the two IMSes participating in an interoperability test shall be unique, i.e. IMS_A and IMS_B shall have no phone 
numbers in common. All public identities belong to the same implicitly registered set. 

Table 1 : HSS sample user profiles 



Private Identity 


Public Identity 1 


Public Identity 2 
(Tel URI) 


Default Public 
Identity 


Filter criteria 


user 1 priv 


user 1 pub 


n.a. 


1 


na 


user 2 priv 


user 2 pub 


e.g. tel:0633348273 


1 


na 


user 3 priv 


user 3 pub 


e.g.tel:0633348274 


2 


na 


user_4_priv 


user_4_pub 


n.a. 


1 


terminating unregistered/INVITE/ 

SESSION_TERMINATED/ 

as-1.ims-a.net 


user 5 priv 


user 5 pub 


n.a. 


1 


TODO 


user_6_priv 


user_6_pub 


n.a. 


1 


TODO 



PubHc user identity may take the form of SIP or TEL URIs (RFC 2806 [9]). 

EXAMPLE 1 : sip : user_ 1 _pub @ ims_a.net 

EXAMPLE 2: tel: 0633348273 @ims_a.net 
Private user identity may take the form of- <imsi>@ims.<xxx>mnc.<yyy>. mcc.3gppnetwork.org 

EXAMPLE 3: 293410100367663@ims.041mnc.293.mcc.3gppnetwork.org 

4.3.2 External IMS Nodes 



4.3.2.1 



UE 



4.3.2.1.1 



Relevant Interfaces 



The UE is considered to act as a stimulus node in this test specification. The Gm interface between the P-CSCF and the 
UE is used as a point of control and observation (PCO) for NNI interoperability tests. 



4.3.2.1.2 



Node Configuration 



The UE should be configured to support the pre-requisites outlined in clause 4.2. The test descriptions in the present 
document assume that a UE supports basic call and messaging functionality, target refresh based on UPDATE and on 
re-INVITE method, message transport via UDP and TCP and the use of at least one of the supplementary services 
HOLD (TS 124 410 [10]), CDIV (TS 124 404 [11]), ACR-CB (TS 124 411 [12]) or (TS 124 407 OIP/OIR [13]). In the 
case that a UE does not meet one or more of these features, only a selected subset of the test descriptions in the present 
document should be used for IMS core network interoperability testing, i.e. test descriptions which do not contain any 
pass criteria related to these features. 
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4.3.2.2 AS 

4.3.2.2.1 Relevant Interfaces 

The application server (AS) is considered to act as a stimulus node in this test specification. The ISC interface between 
the S-CSCF and the AS is used as a Point of Control and Observation (PCO) for NNI interoperability tests. 

4.3.2.2.2 Node Configuration 

The AS should be configured to support the pre-requisites outlined in clause 4.2. The test descriptions in the present 
document assume that an AS supports the use of at least one of the supplementary services HOLD (TS 124 410 [10]), 
CDIV (TS 124 404 [11]), ACR-CB (TS 124 411 [12]) or (TS 124 407 OIP/OIR [13]). 

4.3.3 Supporting IMS Nodes 

4.3.3.1 DNS 

4.3.3.1 .1 Relevant Interfaces 

The Domain Name Service (DNS) is considered as a supporting entity in this test specification. 

4.3.3.1 .2 Node Configuration 

DNS should be configured for appropriate resource record handling as required to support proper resolution of all SIP 
URIs in Request URIs and Route headers. In addition, DNS must support ENUM functionality in order to resolve Tel 
URIs into SIP URIs. As an example, a DNS should have an entry to map E.164 number 0633348273 with user 
user_2_priv @ ims_a.net. 

4.3.4 Test Configurations 

The following architectural test configurations are referenced in the IMS NNI interoperability TDs in the present 
document. They are intended to give a general rather than a specific view of the required IMS SUT(s) connectivity and 
associated UE(s), AS(s) and DNS(s). 

NOTE: In the following figures observable interfaces are indicated as a solid line, non-observable interfaces 
indicated as dashed lines and IBCF assumed to act in a "pass-through" mode if topology hiding is not 
required by a test description. 
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UE 
B 



Gm 



£^ 



PCO 



IMS A 



P-CSCF 



l-CSCF 



Roaming Registration 
CF ROAM REG 



HSS 



^ S-CSCF ^ 



IBCF 



Mw 



^ 



HSS 



S-CSCF 



IBCF 



IMSB 





P-CSCF 


*•# 




L 

1 
1 
} 


l-CSCF 



PO 

Precondition: 

Different network operators acting as home and visited IMS, UE_B roaming in IMS_A (ROAM). UE_B 

not yet registered (REG), neither UE_A nor AS involved , IBCF only if topology hiding required 
Test configuration for: 

Registration requests and responses from UE_B 
Example: 

REGISTER prior to IMS VoIP voice call from UE_B 

Figure 1 : CF_ROAM_REG 
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UE 
A 



Gm 



^ 



PCO 



IMS A 



P-CSCF 



l-CSCF 



Interworking Call 
CF INT CALL 



HSS 



S-CSCF 



[' IBCF 



^ __^ _^ 



DNS 



Mw 



^ 



HSS 



S-CSCF 



f IBCF 



^. 



IMSB 



P-CSCF 



l-CSCF 



Gm 



^- 



PCO 



UE 
B 



PO 

Precondition: 

Different network operators acting as originating and terminating IMS, both UEs or only UE A in home 
networks (INT), both UEs registered, no AS, DNS may be involved, IBCF only if topology hiding 
required 

Test configuration for: 

Requests and responses between UE_A and UE_B in call (CALL) and messaging scenahos 
Unsuccessful initial requests and responses from UE_A (when UE_B is not registered) 

Example: 

InitiallNVITE in IMS VoIP voice call from UE AtoUE B 



Figure 2: CF_INT_CALL 
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UE 
A 



UE 

B 



Gm 






PCO 
Gm 



^i 



PCO 



IMS A 



P-CSCF 



l-CSCF 



Roaming Call 
CF ROAM CALL 



HSS 



S-CSCF 



i IBCF 



Mw 



# 



HSS 



S-CSCF 



f IBCF 



^. ^^ 



IMSB 



P-CSCF 



l-CSCF 



PO 

Precondition: 

Different network operators acting as home IMS for UE_A and UE_B, UE_B roaming (ROAM) in 

network IMS_A, UE_A in home network, both UEs are registered, no AS, IBCF only if topology hiding 

required 
Test configuration for: 

Requests and responses between UEB and UE_A in call (CALL) and messaging scenanos 
Example: 

Initial INVITE in IMS VoIP voice call from UE_B to UE_A 

Figure 3: CF_ROAM_CALL 
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Interworking Application Server 
CF INT AS 



UE 
A 



Gm 



e 



PCO 
ISC 



AS 
A 



m 



PCO 



IMS A 







HSS 




P-CSCF ^ 




f 


S-CSCF 


^^ 




; 


l-CSCF ^ 
J 


s 




BCF 


1 
1 

L 
1 
1 

; 



Mw 







PO 



HSS 



IMSB 



' S-CSCF ' 




' P-CSCF ^ 


>^ . .y 




*'*^ 




flBCF \ 

1 L 


"^ l-CSCF ^ 

V J 



Gm 



e 



UE 
B 



PCO 



Precondition: 

Different network operators acting as originating and terminating IMS, UE_A and UE_B in home 

networks (INT), both UEs registered, only AS for UE_A (AS), IBCF only if topology hiding required 
Test configuration for: 

Requests and responses between AS_A and UEs 
Example: 

Initial INVITE in IMS VoIP voice call unconditionally forwarded to UE_B by AS_A (CPU). AS_A acts 

as routing AS 

Figure 4: CF_INT_AS 
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UE 
A 



UE 

B 



4.4 



Roaming Application Server 
CF ROAM AS 



Gm 



Dr-n > 



PCO 
Gm 



^i 



PCO 



IMS A 



HSS 



P-CSCF 



l-CSCF 



S-CSCF 



IBCF 



^ ____:_ _ 



Mw 



^ 



HSS 



IMSB 



S-CSCF 



P-CSCF 



IBCF 



l-CSCF h 



^., ^_. 



ISC 



fl 



PCO 



AS 
B 



PO 



Precondition: 

Different network operators acting as home IMS for UE_A and UE_B, UE_B roaming (ROAM) in 

IMS_A, UE_A in home network, both UEs or registered, AS for UE B may be involved (AS), IBCF 

only if topology hiding required 
Test configuration for: 

Requests and responses between AS_B and UEs 

Unsuccessful initial requests and responses from UE_A (when UE_B land AS_B are not available) 
Example: 

Initial INVITE IMS VoIP voice call unconditionally forwarded to UE_B by AS_B (CPU) . AS_B acts 

as routing AS 

Figure 5: CF_ROAM_AS 



Use Cases 



Use cases are the basis for interoperability test descriptions. Each use case defines both a generic test sequence, i.e. a set 
of user stimuH and observations for any number of involved IMS external entities (IMS UE, DNS Server and AS) and a 
monitor view of all the resulting messages exchanged at the outer IMS core network interfaces, i.e. a call flow for user, 
Gm, Mw, Ic, DNS and ISC interfaces. The test sequence and call flow are correlated using grey shading. 

For call and messaging related use cases presented in this clause that involve UE interaction it is assumed to follow the 
registration and subscription procedure described in clause 4.2.4 for each UE involved in the test. These procedures are 
not shown here to reduce the size of the call flows. 

Test descriptions defined in clause 4.5 then reference and specialize one of the use cases presented in this clause, 
i.e. generic test sequence and call flow, according to the needs of the one or more test purposes which are associated 
with a test description. 

4.4.1 IMS Registration in a Visited Network 



4.4.1.1 



Description 



UE_B registers in a visiting network. The call flow path and node configuration for this use case corresponds to 
CF_ROAM_REG. 

The test sequence typically associated with this use case when an established session is released is as follows (CFW 
step numbers refer the call flow step numbering). 
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Step 


Action 


CF ROAM REG 


1 


User B triggers registration to IIVIS B 


Step1 


2 


User B is informed about successful registration 


Step 22 



4.4.1 .2 UC_01_R: SIP message flow for IMS registration with CF ROAM 



The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 














1 














User B triggers registration to IIVIS B 


^ 


2 












REGISTER 


UE B sends a REGISTER to IMS A 


y 


3 


REGISTER 


IMS A forwards the REGISTER to IMS B 


y 


4 


401 Unauthorized 


IMS B responds with 401 Unauthorized to 
IMS A 


X 


5 


401 Unauthorized 


IMS A forwards the 401 Unauthorized to UE B 


K 


6 


REGISTER 


UE_B sends the same REGISTER containing 
authentication challenge response to IMS A 


y 


7 


REGISTER 


IMS A forwards the REGISTER to IMS B 


/^ 


8 


200 OK 


IMS B responds with 200 OK 




9 


200 OK 


IMS A forwards the 200 OK response to UE B 




10 


SUBSCRIBE 


IMS A sends a SUBSCRIBE to IMS B 


y 


11 


200 OK 


IMS B responds with a 200 OK 


y 


12 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 


X 


13 


200 OK 


IMS A responds to the NOTIFY with a 200 OK 




14 


SUBSCRIBE 


UE_B sends a SUBSCRIBE (reg event 
package) to IMS A 


y 


15 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE request to 
IMS B 


y 


16 


200 OK 


IMS B responds to the SUBSCRIBE with a 200 
OK 


f 


17 


200 OK 


IMS A forwards the 200 OK response to UE B 


y 


18 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 


X 


19 


NOTIFY 


IMS A forwards the NOTIFY to UE B 




20 


200 OK 


UE B responds to the NOTIFY with a 200 OK 




21 


200 OK 


IMS A forwards the 200 OK to IMS B 




22 




i 










User B is informed about successful registration 



4.4.2 User-initiated VoIP call setup and release 
4.4.2.1 Normal Call 



4.4.2.1.1 



Description 



UE_A places an IMS VoIP call to UE_B. Once the media path is established, the originating user releases the call. The 
call flow path and node configuration for this use case corresponds to CF_INT_CALL in case of interworking and 
CF_ROAM_CALL in case of roaming. 
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The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF INT CALL 


CF ROAM CALL 


1 


User A calls User B 


Step1 


Stepi 


2 


User B is informed of incoming call of User A 


Steps 


Step 10 


3 


User A is informed that UE B is ringing 


Step 1 2 


Step 1 5 


4 


User B answers call 


Step 13 


Step 16 


5 


User A is informed that call has been answered 


Step 17 


Step 21 


6 


User B is informed that the call is established 


Step 21 


Step 26 


7A 


User A ends call 


Step 22A 


Step 27A 


7B 


User B ends call 


Step 22B 


Step 27B 


8A 


User B is informed that call has ended 


Step 26A 


Step 32A 


8B 


User A is informed that call has ended 


Step 26B 


Step 32B 


9A 


User A is informed that call has ended 


Step 30A 


Step 37A 


9B 


User B is informed that call has ended 


Step 30B 


Step 37B 
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4.4.2.1.2 



UC 02 I: SIP Call Flow "Normal Call" with CF INT CALL 



The expected call flow sequence when user A calls user B in an interworking scenario is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














1 


















User A calls User B 


^ 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 


< 


3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


f 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B 


^ 


7 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 


\ 


8 












^ 






User B is informed of incoming call of User A 


9 






/^ 


^ 


• 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 


\ 


11 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 




12 




i 














User A is informed that UE B is ringing 


13 






User B answers call 


k 


14 






{ 


^ 


{ 






200 OK 


UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 




15 


200 OK 


IMS B forwards 200 OK response to IMS A 


\ 


16 


200 OK 


IMS_A forwards the 200 OK response to UE_A 




17 




i 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 




20 


ACK 


IMS B forwards ACK to UE B 




21 












^ 






User B is informed that the call is established 


22A 


















User A ends call 


— > 


23A 
















BYE 


UE A releases the call with BYE 




24A 


BYE 


IMS A forwards BYE to IMS B 




25A 


BYE 


IMS B forwards BYE to UE B 




26A 












^ 






User B is informed that call has ended 


27A 






f 


{ 


^ 






200 OK 


UE B sends 200 OK for BYE 


\ 


28A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




29A 


200 OK 


IMS A forwards the 200 OK response to UE A 




30A 




« — 














User A is informed that call has ended 


22B 


















User B ends call 


k 


23B 






{ 


• 


f 






BYE 


UE B releases the call with BYE 




24B 


BYE 


IMS B forwards BYE to IMS A 




25B 


BYE 


IMS A forwards BYE to UE A 




26B 




« — 














User A is informed that call has ended 


27B 
















200 OK 


UE A sends 200 OK for BYE 




28B 


200 OK 


IMS A forwards 200 OK response to IMS B 




29B 


200 OK 


IMS B forwards the 200 OK response to UE B 




30B 












^ 






User B is informed that call has ended 



4.4.2.1 .3 UC_02_R: SIP Call Flow "Normal Call" with CF_ROAM_CALL 

The expected call flow sequence when user A calls user B in a roaming scenario is: 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 














1 


















User A calls User B 


^ 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_A supports 


y 






3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 






• 


4 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


y 


6 


INVITE 


IMS B forwards the INVITE to IMS A 


\ 


7 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




8 


INVITE 


IMS A forwards the INVITE to UE B 




9 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




10 








k 










User B is informed of incoming call of User A 


11 






f 










180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 




13 


180 Ringing 


IMS B forwards the 180 Ringing response to 
IMS A 




14 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 








15 




i 














User A is informed that UE B is ringing 


16 






User B answers call 


^ 


17 






f 










200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




18 


200 OK 


IMS A forwards 200 OK response to IMS B 




19 


200 OK 


IMS B forwards the 200 OK response to IMS A 




20 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








21 




i 














User A is informed that call has been answered 


22 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 






• 


23 


ACK 


IMS A forwards ACK to IMS B 




24 


ACK 


IMS B forwards ACK to IMS A 




25 


ACK 


IMS A forwards ACK to UE B 




26 








k 










User B is informed that the call is established 


27A 


















User A ends call 


^ 


28A 
















BYE 


UE A releases the call with BYE 






• 


29A 


BYE 


IMS A forwards BYE to IMS B 




30A 


BYE 


IMS B forwards BYE to IMS A 




31A 


BYE 


IMS A forwards BYE to UE B 




32A 








k 










User B is informed that call has ended 


33A 






• 










200 OK 


UE B sends 200 OK for BYE 




34A 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




35A 


200 OK 


IMS B forwards the 200 OK response to IMS A 




36A 


200 OK 


IMS A forwards the 200 OK response to UE A 








37A 




i 














User A is informed that call has ended 


27B 


















User B ends call 


^ 


28B 






{ 










BYE 


UE B releases the call with BYE 




29B 


BYE 


IMS A forwards BYE to IMS B 




30B 


BYE 


IMS B forwards BYE to IMS A 




31B 


BYE 


IMS A forwards BYE to UE A 








32B 




i 














User A is informed that call has ended 


33B 
















200 OK 


UE A sends 200 OK for BYE 






{ 


34B 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




35B 


200 OK 


IMS B forwards the 200 OK response to IMS A 




36B 


200 OK 


IMS_A forwards the 200 OK response to UE_B 
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Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 

IVI 
S 
A 


1 
IVI 

s 

B 














37B 




1 


\y 


1 


1 




User B is informed that call has ended 


^ 1 



The expected call flow sequence when user B calls user A in a roaming scenario is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


\ 

M 
S 
B 














1 


















User B calls User A 


^ 


2 






• 










INVITE 


UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_B supports 


^ 


3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


\ 


4 


INVITE 


IMS A forwards INVITE to IMS B 


• 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


^ 


6 


INVITE 


IMS B forwards the INVITE to IMS A 


\ 


7 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




8 


INVITE 


IMS A forwards the INVITE to UE A 








9 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








10 




d 














User A is informed of incoming call of User B 


11 
















180 Ringing 


UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 






{ 


12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 




13 


180 Ringing 


IMS B forwards the 180 Ringing response to 
IMS A 




14 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE B 




15 








^ 










User B is informed that UE A is ringing 


16 






User A answers call 


^ 


17 
















200 OK 


UE_A responds INVITE with 200 OK to indicate 
that the call has been answered 






{ 


18 


200 OK 


IMS A forwards 200 OK response to IMS B 




19 


200 OK 


IMS B forwards the 200 OK response to IMS A 




20 


200 OK 


IMS_A forwards the 200 OK response to UE_B 




21 








d 










User B is informed that call has been answered 


22 






^ 










ACK 


UE B acknowledges the receipt of 200 OK for 
INVITE 




23 


ACK 


IMS A forwards ACK to IMS B 




24 


ACK 


IMS B forwards ACK to IMS A 




25 


ACK 


IMS A forwards ACK to UE A 


\ 






26 




d 














User A is informed that the call is established 


27A 


















User A ends call 


^ 


28A 
















BYE 


UE A releases the call with BYE 






• 


29A 


BYE 


IMS A forwards BYE to IMS B 




30A 


BYE 


IMS B forwards BYE to IMS A 




31A 


BYE 


IMS A forwards BYE to UE B 




32A 








d 










User B is informed that call has ended 


33A 






y 










200 OK 


UE B sends 200 OK for BYE 




34A 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




35A 


200 OK 


IMS B forwards the 200 OK response to IMS A 




36A 


200 OK 


IMS A forwards the 200 OK response to UE A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 






37A 


















User A is informed that call has ended 


i 


27B 


















User B ends call 


^ 


28B 






/^ 










BYE 


UE B releases the call with BYE 




29B 


BYE 


IMS A forwards BYE to IMS B 


y 


308 


BYE 


IMS B forwards BYE to IMS A 




31B 


BYE 


IMS A forwards BYE to UE A 








32B 




i 














User A is informed that call has ended 


33B 
















200 OK 


UE A sends 200 OK for BYE 






/^ 


34B 


200 OK 


IMS A forwards 200 OK response to IMS B 


y 


35B 


200 OK 


IMS B forwards the 200 OK response to IMS A 




36B 


200 OK 


IMS_A forwards the 200 OK response to UE_B 




37B 








i 










User B is informed that call has ended 



4.4.3 User-initiated call hold and resume 

UE_A places an IMS VoIP call to UE_B. Once the media path is established: 

a) The originating user puts the call on hold, stopping the media stream. The originating user then resumes the 
call. 

b) The terminating user puts the call on hold, stopping the media stream. The terminating user then resumes the 
call. 

The call flow path and node configuration for this use case corresponds to CF_INT_CALL in case of interworking 
and CF_ROAM_CALL in case of roaming. 

Depending on the UE this feature may be implemented either using relNVITE or UPDATE where UPDATE is only 
an optional feature. 



4.4.3.1 



User-initiated call hold and resume using relNVITE 



4.4.3.1.1 



Description 



The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF INT CALL 


CF ROAM CALL 


1 


User A calls User B 


1 


1 


2 


User B is informed of incoming call of User A 


8 


10 


3 


User A is informed that UE B is ringing 


12 


15 


4 


User B answers call 


13 


16 


5 


User A is informed that call has been answered 


17 


21 


6 


User B is presented that call is established 


27 


26 


7A 


User A puts call on hold 


22A 


27A 


7B 


User B puts call on hold 


22B 


27B 


8A 


User B is informed that call on hold 


29A 


36A 


8B 


User A is informed that call on hold 


29B 


36B 


9A 


User A resumes call 


36A 


45A 


9B 


User B resumes call 


36B 


45B 


10A 


User B is informed that call is resumed 


43A 


54A 


10B 


User A is informed that call is resumed 


43B 


54A 


11A 


User A is informed that call is resumed 


47A 


59A 


11B 


User B is informed that call is resumed 


47B 


59B 


12 


User A ends call 


51 


64 


13 


User B is informed that call has ended 


55 


69 


14 


User A is informed that call has ended 


59 


73 
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4.4.3.1 .2 UC_03_I: SIP Call Flow "call hold and resume" using relNVITE with 

CF_INT_CALL 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


1 

M 
S 
A 


1 

M 
S 

B 


U 

E 
B 


u 

s 
e 
r 
B 






1 


















1 JQPr A ppiIIq I JQPr R 


2 












X 




INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_A supports 


^ 


3 


100 Trying 


ll\/IS_A responds with a 100 Trying provisional 
response 


\ 


4 


INVITE 


IMS A forwards INVITE to IMS B 


• 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B 


{ 


7 

Q 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




O 

9 






{ 


f 


f 






180 Ringing 


user b IS inTormeo ot incoming can ot user a 
UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 




12 




d 














User A is informed that UE B is ringing 


13 






User B answers call 


k 


14 






^ 


f 


^ 






200 OK 


UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 


\ 


15 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




16 


200 OK 


IMS A forwards the 200 OK response to UE A 


\ 


17 




d 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 




20 


ACK 


IMS B forwards ACK to UE B 




21 

99A 












^ 






User B is presented that call is in progress 

1 Icor A r»i itc r'all on holH 


23A 












X 




INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 


• 


24A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




25A 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


26A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




27A 


INVITE 


IMS B forwards INVITE to UE B 


f 


28A 

OQ A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




d\df\ 

30A 






f 


{ 


^ 






200 OK 


user b IS inTormeo inai can is on noio 
UE_B responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 


\ 


31A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




32A 


200 OK 


IMS A forwards the 200 OK response to UE A 




33A 


ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




34A 


ACK 


IMS A forwards ACK to IMS B 




35A 


ACK 


IMS B forwards ACK to UE B 




36A 




— > 














User A resumes call 


37A 






N 










INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 




/ 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


u 

s 
e 
r 
B 






38A 






y 










100 Trying 


ll\/IS_A responds with a 100 Trying provisional 
response 




39A 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


40A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




41A 


INVITE 


IMS B forwards INVITE to UE B 


f 


42A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




43A 












> 






User B is informed that call is resumed 


44A 






y 


{ 


y 






200 OK 


UE_B responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 


\ 


45A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




46A 


200 OK 


IMS A forwards the 200 OK response to UE A 


K 


47A 




i 














User A is informed that call is resumed 


48A 
















ACK 


UE A acknowledges the receipt of 200 OK for 
relNVITE 




49A 


ACK 


IMS A forwards ACK to IMS B 




50A 


ACK 


IMS B forwards ACK to UE B 




22B 


















User B puts call on hold 


k 


23B 






{ 


y 


f 






INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 




24B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




25B 


INVITE 


IMS B forwards INVITE to IMS A 




26B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




27B 


INVITE 


IMS A forwards INVITE to UE A 




28B 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 




29B 




i 














User A is informed that call is on hold 


30B 
















200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 


y 


31B 


200 OK 


IMS A forwards 200 OK response to IMS B 


{ 


32B 


200 OK 


IMS B forwards the 200 OK response to UE B 


y 


33B 


ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 


\ 


34B 


ACK 


IMS B forwards ACK to IMS A 




35B 


ACK 


IMS A forwards ACK to UE A 


\ 


36B 












k 






User B resumes call 


37B 






{ 


{ 


y 






INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 


\ 


38B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




39B 


INVITE 


IMS B forwards INVITE to IMS A 




40B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




41 B 


INVITE 


IMS A forwards INVITE to UE A 




42B 


100 Trying 


UE_A optionallyresponds with a 100 Trying 
provisional response 




43B 




i 














User A is informed that call is resumed 


44B 
















200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "sendrecv" 




45B 


200 OK 


IMS A forwards 200 OK response to IMS B 




46B 


200 OK 


IMS_B forwards the 200 OK response to UE_B 




47B 












^ 






User B is informed that call is resumed 


48B 






{ 


y 


{ 






ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 




49B 


ACK 


IMS B forwards ACK to IMS A 


\ 


SOB 


ACK 


IMS A forwards ACK to UE A 




51 


















User A ends call 


1 — > 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 






52 
















BYE 


UE A releases the call with BYE 




53 


BYE 


IMS A forwards BYE to IMS B 




54 


BYE 


IMS B forwards BYE to UE B 




55 












^ 






User B is informed that call has ended 


56 










< 






200 OK 


UE B sends 200 OK for BYE 




57 


200 OK 


IMS B forwards 200 OK response to IMS A 


K 


58 


200 OK 


IMS A forwards the 200 OK response to UE A 




59 




i 














User A is informed that call has ended 



4.4.3.1 .3 UC_03_R: SIP Call Flow "call hold and resume" using relNVITE with 

CF_ROAM_CALL 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 














1 


















User A calls User B 


^ 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE A supports 


< 






3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 






/^ 


4 


INVITE 


IMS A forwards INVITE to IMS B 


f 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


{ 


6 


INVITE 


IMS B forwards INVITE to IMS A 




7 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




8 


INVITE 


IMS A forwards INVITE to UE B 




9 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




10 








i 










User B is informed of incoming call of User A 


11 






y 










180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 


y 


13 


180 Ringing 


IMS B forwards the 180 Ringing response to 
IMS A 




14 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 


K 






15 




i 














User A is informed that UE B is ringing 


16 






User B answers call 


^ 


17 






y 










200 OK 


UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 




18 


200 OK 


IMS A forwards 200 OK response to IMS B 


f 


19 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




20 


200 OK 


IMS A forwards the 200 OK response to UE A 


K 






21 


















User A is informed that call has been answered 


i 


22 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 






{ 


23 


ACK 


IMS A forwards ACK to IMS B 


y 


24 


ACK 


IMS B forwards ACK to IMS A 


\ 


25 


ACK 


IMS A forwards ACK to UE B 




26 








i 










User B is presented that call is established 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 






27A 


















User A puts call on hold 


^ 


28A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 


y 






29A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 






• 


30A 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


31A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


y 


32A 


INVITE 


IMS B forwards INVITE to IMS A 


\ 


33A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




34A 


INVITE 


IMS A forwards INVITE to UE B 




35A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




36A 








k 










User B is informed that call is on hold 


37A 






{ 










200 OK 


UE_B responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 




38A 


200 OK 


IMS A forwards 200 OK response to IMS B 


• 


39A 


200 OK 


IMS B forwards 200 OK response to IMS A 




40A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








41A 


ACK 


UE A acknowledges the receipt of 200 OK for 
relNVITE 






{ 


42A 


ACK 


IMS A forwards ACK to IMS B 


• 


43A 


ACK 


IMS B forwards ACK to IMS A 




44A 


ACK 


IMS A forwards ACK to UE B 




45A 




^ 














User A resumes call 


46A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 


{ 






47A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 






{ 


48A 


INVITE 


IMS A forwards INVITE to IMS B 


f 


49A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


• 


50A 


INVITE 


IMS B forwards INVITE to IMS A 




51A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




52A 


INVITE 


IMS A forwards INVITE to UE B 




53A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




54A 








k 










User B is informed that call is resumed 


55A 






f 










200 OK 


UE_B responds to relNVITE with 200 OK 
indicating media attribute "sendrecv" 




56A 


200 OK 


IMS A forwards 200 OK response to IMS B 


{ 


57A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




58A 


200 OK 


IMS A forwards the 200 OK response to UE A 








59A 




i 














User A is informed that call is resumed 


60A 
















ACK 


UE A acknowledges the receipt of 200 OK for 
relNVITE 








61A 


ACK 


IMS A forwards ACK to IMS B 


f 


62A 


ACK 


IMS B forwards ACK to IMS A 




63A 










• 






ACK 


IMS A forwards ACK to UE B 




27B 


















User B puts call on hold 


^ 


28B 
















INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 


y 


290 
B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


\ 


30B 


INVITE 


IMS A forwards INVITE to IMS B 


y 


31B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




32B 


INVITE 


IMS B forwards INVITE to IMS A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 






33B 






/^ 










100 Trying 


ll\/IS_A responds with a 100 Trying provisional 
response 




34B 


INVITE 


IMS A forwards INVITE to UE A 








35B 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








36B 




i 














User A is informed that call is on hold 


37B 
















200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 


y 




y 


38B 


200 OK 


IMS A forwards 200 OK response to IMS B 


f 


39B 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




40B 


200 OK 


IMS A forwards the 200 OK response to UE B 


\ 


41 B 


ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 




42B 


ACK 


IMS A forwards ACK to IMS B 


f 


43B 


ACK 


IMS B forwards ACK to IMS B 




44B 


ACK 


IMS A forwards ACK to UE A 


K 






45B 








^ 










User B resumes call 


46B 






y 










INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 


y 


47B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


\ 


48B 


INVITE 


IMS A forwards INVITE to IMS B 


y 


49B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


f 


SOB 


INVITE 


IMS B forwards INVITE to IMS A 




51B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




52B 


INVITE 


IMS A forwards INVITE to UE A 


K 






53B 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








54B 




i 














User A is informed that call is resumed 


55B 
















200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "sendrecv" 






y 


56B 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


y 


57B 


200 OK 


IMS B forwards 200 OK response to IMS A 


\ 


58B 


200 OK 


IMS A forwards the 200 OK response to UE B 




59B 








k 










User B is informed that call is resumed 


60B 






f 










ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 




61B 


ACK 


IMS A forwards ACK to IMS B 


y 


62B 


ACK 


IMS B forwards ACK to IMS A 




63B 


ACK 


IMS_A forwards ACK to UE_A 








64 


















User A ends call 


^ 


65 
















BYE 


UE A releases the call with BYE 








66 


BYE 


IMS A forwards BYE to IMS B 


y 


67 


BYE 


IMS B forwards BYE to IMS B 


\ 


68 










{ 






BYE 


IMS B forwards BYE to UE B 




69 








^ 










User B is informed that call has ended 


70 






{ 










200 OK 


UE B sends 200 OK for BYE 




71 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


y 


72 


200 OK 


IMS B forwards 200 OK response to IMS A 


\ 


73 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








74 




i 














User A is informed that call has ended 
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4.4.3.2 



User-initiated call hold and resume using UPDATE 



4.4.3.2.1 



Description 



The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


OF INT CALL 


CF ROAM CALL 


1 


User A calls User B 


1 


1 


2 


User B is informed of incoming call of User A 


8 


10 


3 


User A is informed that UE B is ringing 


12 


15 


4 


User B answers call 


13 


16 


5 


User A is informed that call has been answered 


17 


21 


6 


User B is informed that call is established 


21 


26 


7A 


User A puts call on hold 


22A 


27A 


7B 


User B puts call on hold 


22B 


27B 


8A 


User B is informed that call on hold 


26A 


32A 


8B 


User A is informed that call on hold 


26B 


32B 


9A 


User A resumes call 


30A 


37A 


9B 


User B resumes call 


30B 


37B 


10A 


User B is informed that call is resumed 


34A 


42A 


10B 


User A is informed that call is resumed 


34B 


42B 


11A 


User A is informed that call is resumed 


38A 


47A 


11 


User A is informed that call is resumed 


38B 


47B 


12 


User A ends call 


39 


48 


13 


User B is informed that call has ended 


43 


53 


14 


User A is informed that call has ended 


47 


58 



4.4.3.2.2 UC_04_I: SIP Call Flow "call hold and resume" using UPDATE with 

CF_INT_CALL 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

IVI 

s 

B 


U 

E 
B 


U 
s 
e 
r 
B 














1 


















User A calls User B 


^ 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 




3 


100 Trying 


IMS_AW responds with a 100 Trying provisional 
response 


K 


4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B 


{ 


7 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




8 












^ 






User B is informed of incoming call of User A 


9 






{ 


{ 


f 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 




12 




i 














User A is informed that UE B is ringing 


13 






User B answers call 


k 


14 










^ 






200 OK 


UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 


\ 


15 


200 OK 


IMS_B forwards 200 OK response to IMS_A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


u 

s 
e 
r 
B 






16 






y 










200 OK 


IMS A forwards the 200 OK response to UE A 


K 


17 




i 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 




20 


ACK 


IMS B forwards ACK to UE B 




21 












^ 






User B is informed that call is established 


22A 


















User A puts call on hold 


^ 


23A 
















UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 




24A 


UPDATE 


IMS A forwards UPDATE to IMS B 




25A 


UPDATE 


IMS B forwards UPDATE to UE B 




26A 












^ 






User B is informed that call is on hold 


27A 






y 


/^ 


y 






200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 




28A 


200 OK 


IMS B forwards 200 OK response to IMS A 




29A 


200 OK 


IMS A forwards the 200 OK response to UE A 




30A 




^ 














User A resumes call 


31A 
















UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 




32A 


UPDATE 


IMS A forwards UPDATE to IMS B 




33A 


UPDATE 


IMS B forwards UPDATE to UE B 




34A 












^ 






User B is informed that call is resumed 


35A 






y 


y 


y 






200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 




36A 


200 OK 


IMS B forwards 200 OK response to IMS A 


K 


37A 


200 OK 


IMS A forwards the 200 OK response to UE A 




38A 


















User A is informed that call is resumed 


i 


22B 


















User B puts call on hold 


i 


23B 




y 


y 


y 


y 






UPDATE 


UE_B sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 




24B 


UPDATE 


IMS B forwards UPDATE to IMS A 


K 


25B 


UPDATE 


IMS A forwards UPDATE to UE A 




26B 




User A is informed that call on hold 


K 


27B 


200 OK 


UE_A responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 




28B 


200 OK 


IMS A forwards 200 OK response to IMS B 




29B 


200 OK 


IMS_B forwards the 200 OK response to UE_B 




30B 












i 






User B resumes call 


31B 






y 


y 


y 






UPDATE 


UE_B sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 




32B 


UPDATE 


IMS B forwards UPDATE to IMS A 




33B 


UPDATE 


IMS A forwards UPDATE to UE A 




34B 




i 














User A is informed that call is resumed 


35B 
















200 OK 


UE_A responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 




36B 


200 OK 


IMS A forwards 200 OK response to IMS B 




37B 


200 OK 


IMS_B forwards the 200 OK response to UE_B 




38B 












^ 






User B is informed that call is resumed 


39 


















User A ends call 


^ 


40 
















BYE 


UE A releases the call with BYE 




41 


BYE 


IMS A forwards BYE to IMS B 




42 


BYE 


IMS B forwards BYE to UE B 




43 












^ 






User B is informed that call has ended 


44 






y 


y 


y 






200 OK 


UE B sends 200 OK for BYE 




45 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




46 


200 OK 


IMS A forwards the 200 OK response to UE A 


K 


47 




i 














User A is informed that call has ended 
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4.4.3.2.3 UC_04_R: SIP Call Flow "call hold and resume" using UPDATE with 

CF_ROAM_CALL 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 














1 


















User A calls User B 


^ 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_A supports 


y 






3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


K 






4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards the INVITE to IMS A 




7 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




8 










• 






INVITE 


IMS A forwards the INVITE to UE B 




9 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




10 








k 










User B is informed of incoming call of User A 


11 






{ 










180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 




13 


180 Ringing 


IMS B forwards the 180 Ringing response to 
IMS A 




14 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 








15 




i 














User A is informed that UE B is ringing 


16 






User B answers call 


^ 


17 






{ 










200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




18 


200 OK 


IMS A forwards 200 OK response to IMS B 




19 


200 OK 


IMS B forwards the 200 OK response to IMS A 




20 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








21 




i 














User A is informed that call has been answered 


22 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 






y 


23 


ACK 


IMS A forwards ACK to IMS B 




24 


ACK 


IMS B forwards ACK to IMS A 




25 


ACK 


IMS A forwards ACK to UE B 


\ 


26 








k 










User B is informed that the call is established 


27A 


















User A puts call on hold 


^ 


28A 
















UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 






{ 


29A 


UPDATE 


IMS A forwards UPDATE to IMS B 




30A 


UPDATE 


IMS B forwards UPDATE to IMS A 




31A 


UPDATE 


IMS A forwards UPDATE to UE B 




32A 








^ 










User B is informed that call is on hold 


33A 






y 










200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 




34A 


200 OK 


IMS A forwards 200 OK response to IMS B 




35A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




36A 


200 OK 


IMS A forwards the 200 OK response to UE A 


\ 






37A 




^ 














User A resumes call 


38A 












N 




UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 








39A 


UPDATE 


IMS A forwards UPDATE to IMS B 




/ 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 






40A 










• 


^ 




UPDATE 


IMS B forwards UPDATE to IMS A 


\ 


41A 


UPDATE 


IMS A forwards UPDATE to UE B 




42A 








k 










User B is informed that call is resumed 


43A 






/^ 










200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 




44A 


200 OK 


IMS A forwards 200 OK response to IMS B 


{ 


45A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




46A 


200 OK 


IMS A forwards the 200 OK response to UE A 








47A 




i 














User A is informed that call is resumed 


27B 


















User B puts call on hold 


^ 


28B 
















UPDATE 


UE_B sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 




29B 


UPDATE 


IMS A forwards UPDATE to IMS B 


^ 


308 


UPDATE 


IMS B forwards UPDATE to IMS A 


\ 


31B 






{ 










UPDATE 


IMS A forwards UPDATE to UE A 








32B 




i 














User A is informed that call on hold 


33B 
















200 OK 


UE_A responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 






f 


34B 


200 OK 


IMS A forwards 200 OK response to IMS B 


{ 


35B 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




36B 


200 OK 


IMS A forwards the 200 OK response to UE B 




37B 








^ 










User B resumes call 


38B 






• 










UPDATE 


UE_B sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 




39B 


UPDATE 


IMS A forwards UPDATE to IMS B 


f 


40B 


UPDATE 


IMS B forwards UPDATE to IMS A 




41 B 


UPDATE 


IMS A forwards UPDATE to UE A 








42B 




i 














User A is informed that call is resumed 


43B 
















200 OK 


UE_A responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 






f 


44B 


200 OK 


IMS A forwards 200 OK response to IMS B 


• 


45B 


200 OK 


IMS B forwards 200 OK to IMS A 




46B 


200 OK 


IMS_A forwards the 200 OK response to UE_B 




47B 








^ 










User B is informed that call is resumed 


48 


















User A ends call 


^ 


49 
















BYE 


UE A releases the call with BYE 






f 


50 


BYE 


IMS A forwards BYE to IMS B 


{ 


51 


BYE 


IMS B forwards BYE to IMS A 




52 


BYE 


IMS A forwards BYE to UE B 




53 








k 










User B is informed that call has ended 


54 






f 










200 OK 


UE B sends 200 OK for BYE 




55 


200 OK 


IMS A forwards 200 OK response to IMS B 


{ 


56 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 




57 


200 OK 


IMS A forwards the 200 OK response to UE A 








58 




i 














User A is informed that call has ended 



4.4.4 IMS message exchange between UEs in different networks 
4.4.4.1 Description 

The UE_A sends a MESSAGE to UE_B located in a different network. 

The test sequence typically associated with this use case when an established session is released is as follows (CFW 
step numbers refer the call flow step numbering). 
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Step 


Action 


CF INT CALL 


CF ROAM CALL 


1 


User A sends an instant message 


Step 1 


Step1 


2 


User B is informed about the instant message 


Steps 


Step 6 


3 


Optional: User A is presented a delivery report 


Step 9 


Step 1 1 



4.4.4.2 



UC_05_I: SIP Call flow for IMS Message Exchange with CF_INT_CALL 



The expected call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

IVI 
S 
A 


1 
IVI 

s 

B 


U 

E 
B 


U 
s 
e 
r 
B 














1 


















User A sends an instant message to user B 


^ 


2 
















MESSAGE 


UE A sends MESSAGE to IMS A 




3 


MESSAGE 


IMS A sends MESSAGE to IMS B 




4 


MESSAGE 


IMS B sends MESSAGE to UE B 




5 












^ 






User B is informed about the instant message 


6 








/^ 


< 






200 OK 


UE B sends 200 OK to IMS B 




7 


200 OK 


IMS B sends 200 OK to IMS A 




8 


200 OK 


IMS A sends 200 OK to UE A 




9 




i 














Optional: User A is presented a delivery report 



4.4.4.3 



UC_05_R: SIP Call Flow for IMS Message Exchange with CF_ROAM_CALL 



The expected call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


\ 

M 
S 
B 














1 


















User A sends an instant message to user B 


^ 


2 
















MESSAGE 


UE A sends MESSAGE to IMS A 






y 


3 


MESSAGE 


IMS A forwards MESSAGE to IMS B 


/^ 


4 


MESSAGE 


IMS B forwards MESSAGE to IMSA 




5 


MESSAGE 


IMS A forwards MESSAGE to UE B 


K 


6 








« 










User B is informed about the instant message 


7 
















200 OK 


UE B responds with 200 OK to IMS A 




8 


200 OK 


IMS A forwards 200 OK to IMS B 


f 


9 


200 OK 


IMS B forwards 200 OK to IMS A 




10 


200 OK 


IMS A forwards 200 OK to UE A 


K 






11 




i 














Optional: User A is presented a delivery report 



4.4.5 Supplementary Service Anonymous Communication Rejection 
(ACR) 



4.4.5.1 



Description 



UE_A makes an IMS VoIP call to UE_B while UE_B is roaming in IMS A. UE_A is subscribed to OIR service in 
permanent mode or default presentation restricted temporary mode, UE_B is subscribed to ACR supplementary service. 
The call flow path and node configuration for this use case corresponds to CF_ROAM_AS. 

The test sequence typically associated with this use case when is as follows (CFW step numbers refer the call flow step 
numbering). 
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Step 


Action 


CF ROAM AS 


1 


User A calls User B 


Step1 


2 


User A is informed that call is declined 


Step 1 1 



4.4.5.2 



UC_06_R: SIP message flow for 88 ACR with CF_R0AM_A8 



The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 








1 


























IMS A configured to use OIR AS 


1 




User A calls User B 


^ 


2 


















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE A supports 


< 






3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




























INVITE triggers the OIR IPC in IMS A 


4 


















INVITE 


IMS A forwards INVITE to IMS B 


y 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


K 






















INVITE triggers the ACR IPC in IMS B 


6 






y 






f 






INVITE 


IMS B forwards the INVITE to IMS B AS 


f 


7 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 


y 


8 


603 Decline 


IMS B AS responds with 603 Decline to IMS B 




9 


603 Decline 


IMS B forwards the 603 Decline to IMS A 




10 


603 Decline 


IMS A forwards the 603 Decline to UE A 


K 






11 




i 
















User A is informed of a declined call 


12 


















ACK 


UE A sends ACK to IMS A 








13 


ACK 


IMS A forwards ACK to IMS B 




14 


ACK 


IMS B forwards ACK to IMS B AS 

























4.4.6 Supplementary Service Outgoing Communication Barring (OCB) 



4.4.6.1 



Description 



While roaming in IMS A network, UE_B places an IMS VoIP call to UE_A. UE_B is subscribed to OCB service and 
based on the UE_B identity the OCB service is invoked. The call flow path and node configuration for this use case 
corresponds to CF_ ROAM_AS. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF ROAM AS 


1 


User B calls User A 


Stepi 


2 


User B is informed that call was declined 


Step 1 1 
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4.4.6.2 



UC_07_R: SIP message flow for SS OCB with CF_ROAM_AS 



The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 








1 






1 




















User B calls User A 


^ 


2 










X 








INVITE 


UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_B supports 


y 


3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


K 


4 


INVITE 


IMS A forwards INVITE to IMS B 


y 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 
























INVITE triggers the OCB IPC in IMS B 


6 






y 






y 


X 




INVITE 


IMS B forwards the INVITE to IMS B AS 


y 


7 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 


y 


8 


603 Decline 


IMS B AS returns 603 Decline to IMS B 




9 


603 Decline 


IMS B forwards the 603 Decline to IMS A 


K 


10 


603 Decline 


IMS A forwards the 603 Decline to UE B 








11 




i 
















User B is informed that call was declined 


12 










X 




X 




ACK 


UE B sends ACK to IMS A 








13 


ACK 


IMS A forwards ACK to IMS B 




14 


ACK 


IMS B forwards ACK to IMS B AS 

























4.4.7 Supplementary Service Originating Identification Presentation (OIP) 



4.4.7.1 



Description 



UE_A places an IMS VoIP call to UE_B while UE_B is roaming in IMS A network. UE_B is subscribed to OIP 
service. The call flow path and node configuration for this use case corresponds to CF_ROAM_AS. 

The test sequence typically associated with this use case when is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF ROAM AS 


1 


User A calls User B 


Stepi 


2 


User B is informed of incoming call of User A, user A's identity is 
displayed 


Step 14 


3 


User A is informed that UE B is ringing 


Step 21 


4 


User B answers call 


Step 22 


5 


User A is informed that call has been answered 


Step 29 


6 


User B is informed that the call is established 


Step 36 


7 


User A ends call 


Step 37 


8 


User B is informed that call has ended 


Step 44 


9 


User A is informed that call has ended 


Step 51 
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4.4.7.2 

The expected call flow sequence is: 



UC_08_R: SIP message flow for SS OIP with CF_ROAM_AS 



step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 








1 






1 




















User A calls User B 


^ 


2 










X 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_A supports 


y 






3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


K 






4 


INVITE 


IMS A forwards INVITE to IMS B 


y 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 
























INVITE triggers the OIP IPC in IMS B 


6 










y 


y 


X 




INVITE 


IMS B forwards the INVITE to IMS B AS 


y 


7 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 




8 


INVITE 


IMS B AS returns, possibly modified, INVITE to 
IMS B 




9 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




10 


INVITE 


IMS B forwards the INVITE to IMS A 




11 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




12 


INVITE 


IMS A forwards the INVITE to UE B 


X 


13 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




14 




















User B is informed of incoming call of User A, 
User A's identity is displayed 


i 




15 






y 








X 




180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




16 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 


y 


17 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS_B AS 


y 


18 


180 Ringing 


IMS B AS forwards 180 Ringing response to 
IMS_B 




19 


180 Ringing 


IMS B forwards the 180 Ringing response to 
IMS A 




20 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 


K 






21 




i 
















User A is informed that UE B is ringing 


22 






User B answers call 


^ 


23 






y 












200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




24 


200 OK 


IMS A forwards 200 OK response to IMS B 


y 


25 


200 OK 


IMS_B forwards 200 OK response to IMS_B AS 


y 


26 


200 OK 


IMS_B AS forwards 200 OK response to IMS_B 




27 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 




28 


200 OK 


IMS A forwards the 200 OK response to UE A 


K 






29 




i 
















User A is informed that call has been answered 


30 










X 




X 




ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 








31 


ACK 


IMS A forwards ACK to IMS B 




32 


ACK 


IMS B forwards ACK to IMS B AS 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






33 










/^ 


< 


y 




ACK 


IMS B AS forwards, possibly modified, ACK to 
IMS_B 


\ 


34 


ACK 


IMS B forwards ACK to IMS A 




35 


ACK 


IMS A forwards ACK to UE B 




36 








i 












User B is informed that the call is established 


37 






User A ends call 


^ 


38 










X 








BYE 


UE A releases the call with BYE 






y 


39 


BYE 


IMS A forwards BYE to IMS B 


/^ 


40 


BYE 


IMS_B forwards BYE to IMS_B AS 


y 


41 


BYE 


IMS B AS forwards, possibly modified, BYE to 
IMS_B 




42 


BYE 


IMS B forwards BYE to IMS A 




43 


BYE 


IMS A forwards BYE to UE B 


K 


44 








i 












User B is informed that call has ended 


45 






y 












200 OK 


UE B sends 200 OK for BYE 




46 


200 OK 


IMS A forwards 200 OK response to IMS B 


{ 


47 


200 OK 


IMS_B forwards 200 OK response to IMS_B AS 


y 


48 


200 OK 


IMS_B AS forwards 200 OK response to IMS_B 


\ 


49 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 




50 


200 OK 


IMS A forwards the 200 OK response to UE A 


K 






51 




i 
















User A is informed that call has ended 



4.4.8 Supplementary Service Originating Identification Restriction (OIR) 



4.4.8.1 



Description 



While roaming in IMS A network, UE_B places an IMS VoIP call to UE_A. UE_A is subscribed to OIP service, UE_B 
is subscribed to OIR service in permanent mode or default presentation restricted temporary mode. The call flow path 
and node configuration for this use case corresponds to CF_ROAM_AS. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF ROAM AS 


1 


User B calls User A 


Step1 


2 


User A is informed of incoming call of User B, user B's identity is 
not displayed 


Step 14 


3 


User B is informed that UE A is ringing 


Step 21 


4 


User A answers call 


Step 22 


5 


User B is informed that call has been answered 


Step 29 


6 


User A is informed that the call is established 


Step 36 


7 


User A ends call 


Step 37 


8 


User B is informed that call has ended 


Step 44 


9 


User A is informed that call has ended 


Step 51 



ETS\ 



41 



ETSI TS 186 011-2 V2.1.1 (2009-02) 



4.4.8.2 

The expected call flow sequence is: 



UC_09_R: SIP message flow for SS OIR with CF_ROAM_AS 



step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 

s 

B 








1 






1 




















User B calls User A 


^ 


2 










X 








INVITE 


UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_B supports 


y 


3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


K 


4 


INVITE 


IMS A forwards INVITE to IMS B 


• 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 
























INVITE triggers the OIR IPC in IMS B 


6 






< 






• 


X 




INVITE 


IMS B forwards the INVITE to IMS B AS 


y 


7 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 




8 


INVITE 


IMS B AS returns, possibly modified, INVITE to 
IMS B 




9 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




10 


INVITE 


IMS B forwards the INVITE to IMS A 




11 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




12 


INVITE 


IMS A forwards the INVITE to UE A 






X 


13 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








14 




















User A is informed of incoming call of User B, 
user B's identity is not displayed 


i 




15 














X 




180 Ringing 


UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 






y 


16 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 


• 


17 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS_B AS 


{ 


18 


180 Ringing 


IMS B AS forwards 180 Ringing response to 
IMS_B 




19 


180 Ringing 


IMS B forwards the 180 Ringing response to 
IMS A 




20 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE B 


K 


21 








i 












User B is informed that UE A is ringing 


22 






User A answers call 


^ 


23 














X 




200 OK 


UE_A responds INVITE with 200 OK to indicate 
that the call has been answered 






{ 


24 


200 OK 


IMS A forwards 200 OK response to IMS B 


• 


25 


200 OK 


IMS_B forwards 200 OK response to IMS_B AS 


f 


26 


200 OK 


IMS_B AS forwards 200 OK response to IMS_B 




27 


200 OK 


IMS B forwards the 200 OK response to IMS A 




28 


200 OK 


IMS_A forwards the 200 OK response to UE_B 




29 








i 












User B is informed that call has been answered 


30 


















ACK 


UE B acknowledges the receipt of 200 OK for 
INVITE 




31 


ACK 


IMS A forwards ACK to IMS B 




32 


ACK 


IMS B forwards ACK to IMS B AS 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






33 






/^ 






< 


y 




ACK 


IMS B AS forwards, possibly modified, ACK to 
IMS_B 


\ 


34 


ACK 


IMS B forwards ACK to IMS A 




35 


ACK 


IMS A forwards ACK to UE A 








36 




i 
















User A is informed that the call is established 


37 






User A ends call 


^ 


38 










X 








BYE 


UE A releases the call with BYE 






y 


39 


BYE 


IMS A forwards BYE to IMS B 


/^ 


40 


BYE 


IMS_B forwards BYE to IMS_B AS 


y 


41 


BYE 


IMS B AS forwards, possibly modified, BYE to 
IMS_B 




42 


BYE 


IMS B forwards BYE to IMS A 




43 


BYE 


IMS A forwards BYE to UE B 


K 


44 








i 












User B is informed that call has ended 


45 






y 












200 OK 


UE B sends 200 OK for BYE 




46 


200 OK 


IMS A forwards 200 OK response to IMS B 


{ 


47 


200 OK 


IMS_B forwards 200 OK response to IMS_B AS 


y 


48 


200 OK 


IMS_B AS forwards 200 OK response to IMS_B 


\ 


49 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 




50 


200 OK 


IMS A forwards the 200 OK response to UE A 


K 






51 




i 
















User A is informed that call has ended 



4.4.9 Supplementary Service HOLD 



4.4.9.1 



Description 



UE_A places an IMS VoIP call to UE_B which places the call on HOLD. UE_A will be notified by the AS that the call 
is on hold with voice message. UE_B will resume the call and UE_A will be informed by the AS that the call is 
resumed. 

The test sequence typically associated with this use case when is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF ROAM AS 


1 


User A calls User B 


1 


2 


User B is informed of incoming call of User A 


10 


3 


User A is informed that UE B is ringing 


15 


4 


User B answers call 


16 


5 


User A is informed that call has been answered 


21 


6 


User B is informed that call is established 


26 


7 


User B puts call on hold 


27 


8 


User A is informed that call on hold with AS tone and/or 
announcement 


40 


9 


User B is informed that call on hold 


47 


10 


User B resumes call 


54 


11 


User A is informed that call is resumed 


67 


12 


User B is informed that call is resumed 


81 


13 


User A ends call 


82 


14 


User B is informed that call has ended 


86 


15 


User A is informed that call has ended 


91 
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4.4.9.1.1 



UC_10_R: SIP Call Flow "call hold and resume with AS tones and/or 
announcements" using relNVITE with CF_ROAM_AS 



The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 








1 






1 




















User A calls User B 


^ 


2 


















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_A supports 


y 






3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


K 




• 


4 


INVITE 


IMS A forwards INVITE to IMS B 


• 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


y 


6 


INVITE 


IMS B forwards INVITE to IMS A 


\ 


7 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




8 


INVITE 


IMS A forwards INVITE to UE B 




9 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




10 








k 












User B is informed of incoming call of User A 


11 






{ 












180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 


f 


13 


180 Ringing 


IMS B forwards the 180 Ringing response to 
IMS A 




14 


180 Ringing 


IMS A P- forwards the 180 Ringing response to 
UE A 








15 




i 
















User A is informed that UE B is ringing 


16 






User B answers call 


^ 


17 






{ 












200 OK 


UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 




18 


200 OK 


IMS A forwards 200 OK response to IMS B 


• 


19 


200 OK 


IMS B forwards 200 OK response to IMS A 




20 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








21 




i 
















User A is informed that call has been answered 


22 


















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 






y 


23 


ACK 


IMS A forwards ACK to IMS B 


{ 


24 


ACK 


IMS B forwards ACK to IMS A 




25 


ACK 


IMS A forwards ACK to UE B 


\ 


26 








k 












User B is informed that call is established 


28 






User B puts call on hold 


— > 


28 


















INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 


• 


29 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




30 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


31 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




32 


INVITE 


IMS B sends relNVITE to AS B 


f 


33 


100 Trying 


AS_B optionally responds with a 100 Trying 
provisional response 


• 


35 


INVITE 


AS B sends relNVITE to IMS B 




35 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




36 












{ 






INVITE 


IMS B forwards relNVITE to IMS A 




37 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 


A 
S 
B 






38 






y 












INVITE 


IMS A forwards relNVITE to UE A 


K 






39 


100 Trying 


UE _A optionally responds with a 100 Trying 
provisional response 








40 




















User A is informed that call is on hold (with tone 
and/or announcement) 


i 




41 


















200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 






{ 


42 


200 OK 


IMS A forwards 200 OK response to IMS B 


y 


43 


200 OK 


IMS B forwards 200 OK response to AS B 


f 


44 


200 OK 


AS_B forwards 200 OK response to IMS_B 




45 


200 OK 


IMS B forwards 200 OK response to IMS A 


\ 


46 


200 OK 


IMS A forward the 200 OK to UE B 




47 








k 












User B is informed that the call is on hold 


48 


















ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 


f 


49 


ACK 


IMS A forwards ACK to IMS B 


• 


50 


ACK 


IMS B forwards ACK to AS B 


y 


51 


ACK 


AS B forwards ACK to IMS B 


\ 


52 


ACK 


IMS B forwards ACK to IMS A 




53 


ACK 


IMS A forwards ACK to UE B 




54 








^ 












User B resumes call 


55 






{ 












INVITE 


UE_B sends second relNVITE message 
indicating media attribute "sendrecv" (Call 
Resume) 


y 


56 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


\ 


57 


INVITE 


IMS A sends relNVITE to IMS B 


• 


58 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


• 


59 


INVITE 


IMS B sends relNVITE to AS B 


{ 


60 


100 Trying 


AS_B optionally responds with a 100 Trying 
provisional response 


y 


61 


INVITE 


AS B forwards INVITE to IMS B 


\ 


62 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




63 


INVITE 


IMS B sends relNVITE to IMS A 




64 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




65 


INVITE 


IMS A forwards relNVITE to UE A 








66 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








67 




i 
















User A is informed that call is resumed 


68 


















200 OK 


UE_A sends the 200 OK indicating media 
attribute "sendrecv" to IMS A 






{ 


69 


200 OK 


IMS A forwards 200 OK response to IMS B 


• 


70 


200 OK 


IMS B forwards 200 OK response to AS B 


f 


71 


200 OK 


AS B forwards the 200 OK for INVITE 




72 


200 OK 


IMS B forwards 200 OK to IMS A 




73 


200 OK 


IMS A forwards 200 OK to UE B 




74 








^ 












User B is informed that call is resumed 


75 


















ACK 


UE B sends ACK to IMS A 




76 


ACK 


IMS A forwards ACK to IMS B 




77 


ACK 


IMS B forwards ACK to AS B 


{ 


78 


ACK 


AS B forwards ACK to IMS B 




79 






• 






y 






ACK 


IMS B forwards ACK to IMS A 


\ 


80 


ACK 


IMS A forwards ACK to UE A 








81 




i 














ACK 


User A is informed that call resumed 


82 






User A ends call 


^ 


83 


















BYE 


UE A releases the call with BYE 








84 


BYE 


IMS A forwards BYE to IMS B 




^ 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 


A 
S 
B 






85 










y 








BYE 


IMS B forwards BYE to UE B 


K 




86 








i 












User B is informed that call has ended 


87 






y 












200 OK 


UE B sends 200 OK for BYE 




88 


200 OK 


IMS A forwards 200 OK response to IMS B 


< 


89 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




90 


200 OK 


IMS A forwards the 200 OK response to UE A 


K 






91 




i 
















User A is informed that call has ended 



4.4.10 Supplementary Service Call Forward Unconditional (CFU) 
4.4.10.1 Description 

UE_A places an IMS VoIP call to UE_B which has CFU activated towards user UE_B2 which is located in IMS_A. 
UE_A may be notified by the AS that the call is forwarded. UE_B2 answers the call without previous ringing 
indication. The call is released by UE_A. 

The test sequence typically associated with this use case when is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF ROAM AS 


1 


User A calls User B 


1 


2 


User A may be informed of call diversion 


11 


3 


User B2 answers call 


19 


4 


User A is informed that call has been answered 


26 


6 


User 82 is informed that call is established 


32 


7 


User A ends call 


33 


8 


User B is informed that call has ended 


37 


9 


User A is informed that call has ended 


42 
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4.4.1 0.1 .1 UC_1 1_R: SIP Call Flow "Communication Forwarding unconditional" with 

CF_ROAM_AS 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 

e 

r 

B2 


U 

E 
B2 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 




















User A calls User B 


^ 


2 


















INVITE 


UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE_A supports 


y 






3 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 








4 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


5 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 
























INVITE triggers the CPU IPC in IMS B 


6 


















INVITE 


IMS B forwards the INVITE to AS B 


• 


7 


100 Trying 


AS_B optionally responds with the 100 
Trying to IMS B 
























AS B applies the CDIV CPU procedure 


8 






y 








f 




181 Call is 

being 

forwarded 


AS_B indicates optionally to IMS_B that 
call has been forwarded 




9 


181 Call is 

being 

forwarded 


IMS_B indicates to IMS_A that call has 
been forwarded 


\ 


10 


181 Call is 

being 

forwarded 


IMS_A indicates that call to UE_B has 
been forwarded 








11 




i 
















User A may be informed of call diversion 


12 














f 




INVITE 


AS B returns, possibly modified, INVITE 
to IMS B 




13 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




14 


INVITE 


IMS B forwards the INVITE to IMS A 


\ 


15 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




16 


INVITE 


IMS A forwards the INVITE to UE B2 




17 


100 Trying 


UE_B2 optionally responds with a 100 
Trying provisional response 




18 




















User B2 is informed of incoming call of 
User A 


k 




19 




User B2 answers call 


^ 


20 






f 












200 OK 


UE_B2 responds to INVITE with 200 OK 
to indicate that the call has been 
answered 




21 


200 OK 


IMS A forwards 200 OK response to 
IMS B 


f 


22 


200 OK 


IMS B forwards 200 OK response to 
AS B 


y 


23 


200 OK 


AS B returns, possibly modified, 200 OK 
to IMS B 


\ 


24 


200 OK 


IMS B forwards 200 OK response to 
IMS A 




25 


200 OK 


IMS A forwards 200 OK response to 
UE A 








26 




















User A is informed that call has been 
answered 


i 




27 


















ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B2 


u 

E 
B2 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






28 


















ACK 


IMS A forwards ACK to IMS B 




29 


ACK 


IMS B forwards ACK to AS B 


< 


30 


ACK 


AS B returns, possibly modified, ACK to 
IMS B 




31 


ACK 


IMS B forwards ACK to UE B2 


K 






32 




















User B2 is informed that call is 
established 


i 




33 




User A ends call 


^ 


34 


















BYE 


UE A releases the call with BYE 






< 


35 


BYE 


IMS A forwards BYE to IMS B 




36 


BYE 


IMS B forwards BYE to UE B 






37 








i 












User B is informed that call has ended 


38 






< 












200 OK 


UE B sends 200 OK for BYE 




39 


200 OK 


IMS A forwards 200 OK response to 
IMS B 


/^ 


40 


200 OK 


IMS B forwards 200 OK response to 
IMS A 




41 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








42 




i 
















User A is informed that call has ended 



4.5 Test Descriptions 



This clause introduces interoperability Test Descriptions (TDs) which realize one or more IMS NNI test purposes of 
TS 186 011-1 [2]. 

Each TD is defined on the basis of one of the generic use cases forms presented in the previous clause. Each test 
sequence step in a TD includes also a reference to a specific call flow step of the generic use case. Call flow steps which 
are associated with the test body are repeated after each TD and include any modifications necessary to adapt the 
generic use case. In the adapted call flow steps that are associated with user interactions are shown shaded and steps 
which have pass criteria are associated with are shown in bold. 

Note that the expected test sequence may only show the Call Flow that affects the test. 

In the tabulations which follow, all references are to TS 124 229 [1]. 
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4.5.1 General Capabilities 



4.5.1.1 



SIP messages longer than 1 500 bytes 



Interoperability Test Description 


Identifier: 


ID IMS 0001 


Summary: 


IMS CN components shall support SIP messages greater than 1 500 bytes 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 




TP IMS 4002 1 


clause 4.2A §1 


Use Case ref.: 


UC 05 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A and IMS_A configured to use TCP for transport 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered user of IMS B using any user identity 




Test Sequence: 


Step 




1 


User A sends message to User B with more than 1 500 characters 


2 


Verify that user B receives message from user A 




Conformance 
Criteria: 


Check 




1 


TP_IMS_4002_01 in GFW step 3 (MESSAGE) 
ensure that { 
when { UE_A sends a MESSAGE to UE_B 

containing a Message_Body greater than 1 500 bytes } 
then { IMS_B receives the MESSAGE 

containing the Message Body greater than 1 500 bytes } 

} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














1 


















User A sends an instant message to user B 


^ 


2 
















MESSAGE 


UE A sends MESSAGE to IMS A 




3 


MESSAGE 


IMS_A sends MESSAGE to IMS_B with via 
header indicating TCP 




4 


MESSAGE 


IMS B sends MESSAGE to UE B 




5 












^ 






User B is informed about the instant message 


6 






/^ 


< 


y 






200 OK 


UE B sends 200 OK to IMS B 


K 


7 


200 OK 


IMS B sends 200 OK to IMS A 




8 


200 OK 


IMS A sends 200 OK to UE A 




9 




i 














Optional: User A is presented a delivery report 
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4.5.2 Registration and De-registration 



4.5.2.1 



First time registration in a visited IMS network 



Interoperability Test Description 


Identifier: 


ID IMS 0002 


Summary: 


First time registration in a visited IIVIS network 


Configuration: 


CF ROAM REG 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5011 01 


clause 5.2.2 §2 


IP IMS 5011 02 


clause 5.2.2 §2 


IP IMS 5044 01 


clause 5.2.3 §1 


IP IMS 5089 01 


clause 5.4.1.2.1 §6 


IP IMS 5092 01 


clause 5.4.1.2.2 §1 


IP IMS 5096 01 


clause 5.4.2.1.1 §1 


Use Case ref.: 


UC 01 R 




Pre-test 


• HSS of IMS_B is configured according to table 1 




conditions: 


• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• UE_B not registered in IMS_B 

• IMS A within the trust domain of IMS B 






^^^■n 


H 


Test Sequence: 


Step 




1 


User B registers in IMS B using any valid user identity 


2 


Verify that UE B shows successful registration 


^^ 


Conformance 
Criteria: 


Check 


J 


1 


TP_IMS_501 1_01 in CFW step 3 (REGISTER): 








ensure that { 








when { UE_B sends an unprotected REGISTER to IMS_A 








containing a Security-Client header} 








then { IMS_A sends the REGISTER to IMS_B 








containing a Path_header 








containing P-CSCF_SIP_URI of IMS_A and 








containing a Require_header 








containing a path_option_tag and 








containing a P-Charging-Vector_header 








containing an icid_parameter and 








containing a Authorization_header 








containing an integrity-protected_parameter 








indicating no 








not containing a Security-Verify that_header and 








not containing a Security-Client_header and 








containing a P-Visited-Network-ID_header 








indicating 'the visited network at the home network'} 
} 




2 


TP_IMS_501 1_02 in CFW step 7 (REGISTER): 








ensure that { 








when { UE_B sends a protected REGISTER to IMS_A 








containing a Security-Client header} 








then { IMS_A sends the REGISTER to IMS_B 








containing a Path_header 








containing P-CSCF_SIP_URI of IMS_A and 








containing a Require_header 








containing a path_option_tag and 








containing a P-Charging-Vector_header 








containing an icid_parameter and 








containing a Authorization_header 








containing an integrity-protected_parameter 








indicating yes 








not containing a Security-Verify that_header and 








not containing a Security-Client_header and 








containing a P-Visited-Network-ID_header 








indicating 'the visited network at the home network'} 
} 
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Interoperability Test Description 



TP_IMS_5044_01 in CFW step 15 (SUBSCRIBE): 
ensure that { 
when { IMS_A receives a 200_response from IMS_B 

} 
then { IMS_A sends a SUBSCRIBE to IMS_B 
containing a Request_URI 
indicating 'the resource to which the P-CSCF wants 
to subscribe to' and 
containing a From_header 

indicating P-CSCF_SIP_URI of IMS_A and 
containing a To_header 

indicating the default_public_user_identity of UE_B and 
containing an Event_header 
indicating the reg_event_package and 
containing an Expires_header 
set to 'a value greater than the one in the Expires_header 
of the 200_response' and 
containing a P-Asserted-ldentity_header 

set to the P-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
containing an icid_parameter } 
L 



TP_IMS_5089_01 in CFW step 4 (401 Unauthorized): 
ensure that { 
when { UE_B sends an initial REGISTER to IMS_B and 
IMS_A sends the REGISTER to IMS_B 
containing an Authorization_header 
(not containing an integrity-protected_parameter or 

containing an integrity-protected_parameter indicating no) } 
then { IMS_B sends a 401_response to IMS_A 
containing an WWW-Authenticate_header 
containing a realm_parameter 

indicating the operatorjdentifier of IMS_B and 
containing a nonce_parameter 
(containing a RAND_parameter and 
containing an AUTN_parameter) and 
containing an algorithm_parameter 

indicating AKAv1-MD5 and 
containing an ik_parameter and 
containing a ck_parameter } 

L 



TP_IMS_5092_01 in CFW step 8 (200 Ok): 
ensure that { 
when { UE_B sends a protected REGISTER to IMS_B and 
IMS_A sends the REGISTER to IMS_B 
containing an Authorization_header 

containing an integrity-protected_parameter indicating yes } 
then { IMS_B sends 200_response to IMS_A 

containing the same Path_header as in the protected REGISTER 
and 

containing a P-Associated-URI_header 

containing all registered_public_identities and 'its 
associated set of implicitly registered public user identities ' 
indicating (first the default_public_user_identity and 
no barredjDublic_user_identities) and 
containing a Service-Route_header 

indicating the S-CSCF_SIP_URI of IMS_B and 
containing a Contact_header 
indicating 'all contact addresses' 

for the default_public_user_identity of UE_B } 
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Interoperability Test Description 



TP_IMS_5096_01 in CFW step 16 (200 Ok): 
ensure that { 
when { 

IMS_B receives a SUBSCRIBE from UE_B via IMS_A 
containing an Event_header indicating the reg_event_package } 
then{ 

IMS_B sends a 200_response to UE_B 
containing an Expires_header 
indicating 'the same or lower expiry time than 
specified in the initial SUBSCRIBE'} 
1 



Step 


Direction 


Message 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 

s 

B 














1 














User B registers in IIVIS B 


^ 


2 






X 






REGISTER 


UE B sends a REGISTER to IMS A 


/^ 


3 


REGISTER 


IMS A forwards the REGISTER to IMS B 


• 


4 


401 Unauthorized 


IMS B responds with 401 Unauthorized to 
IMS A 


X 


5 


401 Unauthorized 


IIVIS A forwards the 401 Unauthorized to UE B 




6 


REGISTER 


UE_B sends the same REGISTER containing 
authentication challenge response to IMS A 


f 


7 


REGISTER 


IMS A forwards the REGISTER to IMS B 


{ 


8 


200 OK 


IMS_B responds with 200 OK 


X 


9 


200 OK 


IMS A forwards the 200 OK response to UE B 




10 


SUBSCRIBE 


IMS A sends a SUBSCRIBE to IMS B 


{ 


11 


200 OK 


IMS_B responds with a 200 OK 


• 


12 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 




13 


200 OK 


IMS A responds to the NOTIFY with a 200 OK 


X 


14 


SUBSCRIBE 


UE_B sends a SUBSCRIBE (reg event 
package) to IMS A 


• 


15 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE request to 
IMS B 


^ 


16 


200 OK 


IMS_B responds with 200 OK 


\ 

^ 


17 


200 OK 


IMS A forwards the 200 OK response to UE B 


{ 


18 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 


X 


19 


NOTIFY 


IMS A forwards the NOTIFY to UE B 


X 


20 


200 OK 


UE B responds to the NOTIFY with a 200 OK 




21 


200 OK 


IMS A forwards the 200 OK to IMS B 




22 




i 










User B is informed about successful registration 
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4.5.2.2 



Multiple entry points, no response from first entry point on REGISTER 



Interoperability Test Description 


Identifier: 


ID IMS 0003 


Summary: 


Check that the IMS chooses a second entry point to the home network of a user that 
requested registration, if the first entry point does not answer. 


Configuration: 


OF ROAM REG 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5203 01 


clause 5.2.2 §26 


IP IMS 5402 01 


clause 5.10.2.1 §1 


Use Case ref.: 


UC 01 R 


^m I 


Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• IMS_A configured with multiple entry points for IMS_B 

• First entry point determined by the IMS A pointing to a non-existing component 
in IMS B 




Test Sequence: 


Step 




1 


User B registers in IMS B using any user identity 


2 


Verify that UE B shows successful registration 




Conformance 
Criteria: 


Check 


J 


1 


TP_IMS_5203_01 in GFW step 4 (REGISTER): [P-CSCF] 
ensure that { 

when { IMS_A receives no response from IMS_B } 

then { IMS A sends the REGISTER to another entry point of IMS B } 
} 




2 


TP_IMS_5402_01 in GFW step 4 (REGISTER): [IBGF] 
ensure that { 

when { UE_B sends a REGISTER to IMS_A and 
IMS_B does not send a response to IMS_A } 

then { IMS A sends the original REGISTER to another entry point of 
IMS Bj 

} 
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Step 


Direction 


IVIessage 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 














1 














User B activates the UE in the home network 


^ 


2 








X 




REGISTER 


UE B sends a REGISTER to IMS A 


y 


3 


REGISTER 


IMS_A forwards the REGISTER to first entry 
point defined for ll\/IS_B 








No response from IIVIS B 


4 


REGISTER 


ll\/IS_A sends a REGISTER to another entry 
point defined for IMS B 


y 


5 


401 Unauthorized 


IIVIS B responds with 401 Unauthorized to 
IMS A 


X 


6 


401 Unauthorized 


IMS A forwards the 401 Unauthorized to UE B 


K 


7 


REGISTER 


UE_B sends the same REGISTER containing 
authentication challenge response to IMS A 


y 


8 


REGISTER 


IMS A forwards the REGISTER to IMS B 


/^ 


9 


200 OK 


IMS_B responds with 200 OK 




10 


200 OK 


IMS A forwards the 200 OK response to UE B 


K 


11 


SUBSCRIBE 


IMS A sends a SUBSCRIBE to IMS B 


f 


12 


200 OK 


IMS B responds with a 200 OK 


y 


13 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 


X 


14 


200 OK 


IMS A responds to the NOTIFY with a 200 OK 




15 


SUBSCRIBE 


UE_B sends a SUBSCRIBE (reg event 
package) to IMS A 


y 


16 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE request to 
IMS B 


y 


17 


200 OK 


IMS B responds to the SUBSCRIBE with a 200 
OK 


f 


18 


200 OK 


IMS A forwards the 200 OK response to UE B 


y 


19 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 


X 


20 


NOTIFY 


IMS A forwards the NOTIFY to UE B* 




21 


200 OK 


UE B responds to the NOTIFY with a 200 OK 




22 


200 OK 


IMS A forwards the 200 OK to IMS B 




23 




i 










User B is informed about successful registration 
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4.5.2.3 



403 response to REGISTER from an un-trusted domain 



Interoperability Test Description 


Identifier: 


TD IMS 0004 


Summary: 


403 response is sent when attempting registration from a different trust domain 


Configuration: 


CF ROAM REG 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5129 01 


clause 5.3.1.2 §1 


TP IMS 5411 01 


clause 5.10.3.1 §1 


Use Case ref.i 


UC 01 R 




Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• IMS A and IMS B are in different trust domains 


1^^^^" 


■1 


Test Sequence: 


Step 


J 


1 


User B registers in IMS B using any user identity 


2 


Verify that UE B shows unsuccessful registration 


^ 




Conformance 
Criteria: 


Check 


i 


1 


TP_IMS_5129_01 in CFW step 3 (REGISTER) [l-CSCF]: 
ensure that { 

when { UE_B sends an initial REGISTER to IMS_B 
and IMS_B receives the REGISTER} 

then { IMS B sends a 403 response to IMS A } 
} 


2 


TP_IMS_541 1_01 in CFW step 3 (REGISTER) [IBGF]: 
ensure that { 

when { UE B sends a REGISTER to IMS B and 
IMS_B sends the REGISTER to IMS_A } 

then { IMS B sends a 403 response to IMS A } 
} 



Step 


Direction 


Message 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 














1 














User B activates the UE in a visited network 


^ 


2 








X 




REGISTER 


UE B sends a REGISTER to IMS A 


y 


3 


REGISTER 


IMS A forwards the REGISTER to IMS B 


< 


4 


403 Forbidden 


IMS B responds with 403 Forbidden to 
IMS A 




5 


403 Forbidden 


IMS A forwards the 403 Forbidden to UE B 




6 














User B is informed about the registration is 
rejected 


i 
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4.5.2.4 Network initiated deregistration upon receipt of a new registration with new 

contact information 



Interoperability Test Description 


Identifier: 


TD IMS 0005 


Summary: 


Network initiated deregistration upon receipt of a new registration with new contact 
information 


Configuration: 


CF ROAM REG 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5088 01 


clause 5.4.1.2.1 §1 


Use Case ref.: 


UG 01 R 




Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• UE_B has been registered using any user identity in IMS_B via IMS_A but has 
then physically unplugged, i.e. without de-registration 




Test Sequence: 


Step 


1 


1 


UE B connects to IMS B 


2 


Verify that UE B shows successful registration 


Conformance 
Criteria: 


Check 


^ 


1 


TP_IMS_5088_01 in GFW step 2 (REGISTER) and 6 (NOTIFY): 
ensure that { 
when { UE_B sends an initial REGISTER to IMS_B 
containing an Authorization_header 
not containing an integrity-protected_parameter or 
containing an integrity-protected parameter indicating no } 
then { IMS_B sends a NOTIFY to IMS_A 
containing a Request URI 

indicating the P-CSCF_SIP_URI of IMS_A and 
containing an Event_header 

containing the reg_event_package and 
containing a P-Charging-Vector_header 

containing an icid_parameter and 
containing a Route_header 

indicating the original Route_header from SUBSCRIBE and 
containing a Message_Body -- XML 

containing for each registered_public_identity of UE_B 
a registration_element 
(containing an aor_attribute 

indicating registered_public_identity of UE_B and 
containing a state_attribute 
indicating terminated and 
containing a contact_subelement 
(containing an event_attribute 

indicating deactivated or rejected 
containing a state_attribute indicating terminated and 
containing a URI_subelement 
indicating the contact address of UE B) 
)} 
} 
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Step 


Direction 


IVIessage 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 














1 














User B connects UE B to IMS B 


^ 


2 












REGISTER 


UE B sends a REGISTER to IMS B 


y 




3 


401 Unauthorized 


IMS B responds with 401 Unauthorized to 
UE B 




X 


4 


REGISTER 


UE B sends a REGISTER to IMS B 


y 




5 


200 OK 


IMS B responds with 200 OK to UE B 




/^ 


6 


NOTIFY 


IMS B sends a NOTIFY to IMS A 


X 


7 


200 OK 


IMS A responds with a 200 OK IMS B 




8 














User B is informed about the successful re- 
registration 


i 
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4.5.2.5 



Network initiated deregistration by the S-CSCF 



Interoperability Test Description 


Identifier: 


ID IMS 0006 


Summary: 


Ensure that the network can initiate user de-registration, e.g., when a user runs out of 




credit 




Configuration: 


CF ROAM REG 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5093 01 


clause 5.4.1.5 §6 


Use Case ref.i 


UC 01 R 


-J 


Pre-test 


• HSS of IMS_B is configured according to table 1 


^M 


conditions: 


• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• UE_B registered in IMS_B using any user identity 

• IMS A within the trust domain of IMS B 




¥ 


^^^^m 


1 


Test Sequence: 


Step 




1 


IMS B is triggered manually to de-register user B 


2 


Verify that UE B shows successful de-registration 




Conformance 
Criteria: 


Check 


.1 


1 


TP_IMS_5093_01 in CFW step 23 








ensure that { 








when { IMS B receives an network originated deregistration event } 








then{ 








IIVIS B sends a NOTIFY to IMS A 








containing a Request_URI 








indicating UE_B and 








containing an Event_header 








indicating the reg_event_package and 








containing a P-Charging-Vector_header 








containing an icid_parameter and 








containing a Route_header 








indicating the original Route_header from SUBSCRIBE and 








containing a Message_Body - XML 








containing for each registered_public_identity of UE_B 








a registration_element 








(containing an aor_attribute 








indicating registered_public_identity of UE_B and 








containing a state_attribute 








indicating terminated and 








containing a contact_subelement 








(containing an event_attribute 








indicating deactivated or rejected 








containing a state_attribute indicating terminated and 








containing an URI_subelement 








indicating the contact address of UE B) and 








IMS B sends a NOTIFY to IMS A 








containing a Request URI 








indicating P-CSCF_SIP_URI of IMS_A and 








containing an Event_header 








indicating the reg_event_package and 








containing a P-Charging-Vector_header 








containing an icid_parameter and 








containing a Route_header 








indicating the original Route_header from SUBSCRIBE and 








containing a Message_Body - XML 








containing for each registered_public_identity of UE_B 








a registration_element 








(containing an aor_attribute 








indicating registered_public_identity of UE_B and 








containing a state_attribute 








indicating terminated and 








containing a contact_subelement 








(containing an event_attribute 








indicating deactivated or rejected and 
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Interoperability Test Description 



containing a state_attribute indicating terminated and 
containing an URI_subeiement 
indicating tlie contact_address of UE_B) } 



Step 


Direction 


Message 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 




























IMS B is triggered to de-register user B 


23 






y 


y 




NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's de-registration 




24 


NOTIFY 


MS_B sends a NOTIFY to UE_B, containing 
UE B's de-registration 




25 




i 










User B is informed about de-registration 
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4.5.2.6 



Network initiated re-authentication by the S-CSCF 



Interoperability Test Description 


Identifier: 


ID IMS 0007 


Summary: 


Ensure that the network can initiate user re-authentication 


Configuration: 


CF ROAM REG 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5094 01 


clause 5.4.1.6 §2 


Use Case ref.: 


UC 01 R 




Pre-test 


• HSS of IMS_B is configured according to table 1 




conditions: 


• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• UE_B registered in IMS_B using any user identity 

• IMS_A within the trust domain of IMS_B 

• Event received in S-CSCF of IMS B to re-authenticate UE B 




w 




1 


Test Sequence: 


Step 




1 


IMS B network is triggered to re-authenticate user B 


2 


Verify that UE B shows successful registration 


-4 






Conformance 
Criteria: 


Check 


j| 


1 


TP_IMS_5094_01 in CFW step 23 








ensure that { 








when { IMS B receives an network originated reauthentication event} 








then{ 








IMS_B sends a NOTIFY to UE_B 








containing a Request_URI 








indicating UE_B and 








containing an Event_header 








indicating the reg_event_package and 








containing a P-Charging-Vector_header 








containing an icid_parameter and 








containing a Route_header 








indicating the original Route_header from SUBSCRIBE and 








containing a Message_Body ~ XML 








containing for each registered_public_identity of UE_B 








a registration_element 








(containing an aor_attribute 








indicating a registered_public_identity of UE_B and 








containing a state_attribute 








indicating active and 








containing a contact_subelement 








(containing an event_attribute 








indicating shortened and 








containing a state_attribute indicating active and 








containing an URI_subelement 








indicating the contact_address of UE_B and 








containing an expiry attribute) and 








IMS_B sends a NOTIFY to IMS_A - P-CSCF 








containing a Request URI 








indicating the P-CSCF_SIP_URI of IMS_A and 








containing an Event_header 








indicating the reg_event_package and 








containing a P-Charging-Vector_header 








containing an icid_parameter and 








containing a Route_header 








indicating the original Route_header from SUBSCRIBE and 








containing a Message_Body ~ XML 








containing for each registered_public_identity of UE_B 








a registration_element 








(containing an aor_attribute 








indicating a registered_public_identity of UE_B and 








containing a state_attribute 








indicating active and 








containing a contact_subelement 








(containing an event attribute 
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Interoperability Test Description 



indicating sliortened and 
containing a state_attribute indicating active and 
containing an URI_subeiement 

indicating ttie contact_address of UE_B and 
containing an expiry_attribute) } 



Step 


Direction 


Message 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


\ 

M 
S 
B 




























IMS B is triggered to re-authenticate user B 


23 






y 


• 




NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's re-authentication 


N 


24 


NOTIFY 


ll\/IS_B sends a NOTIFY to UE_B, containing 
UE re-authentication 


K 


25 


REGISTER 


UE_B sends REGISTER containing 
authentication challenge response to IIVIS A 


y 


26 


REGISTER 


IMS A forwards the REGISTER to IMS B 


f 


27 


200 OK 


IMS B responds with 200 OK 




28 


200 OK 


IMS A forwards the 200 OK response to UE B 




29 


SUBSCRIBE 


IMS A sends a SUBSCRIBE to IMS B 


y 


30 


200 OK 


IMS B responds with a 200 OK 




31 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 


N. 


32 


200 OK 


IMS A responds to the NOTIFY with a 200 OK 


N 


33 


SUBSCRIBE 


UE_B sends a SUBSCRIBE (reg event 
package) to IMS A 


f 


34 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to IMS B 


• 


35 


200 OK 


IMS B responds to the SUBSCRIBE with a 200 
OK 


{ 


36 


200 OK 


IMS A forwards the 200 OK response to UE B 


y 


37 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 




38 


NOTIFY 


IMS A forwards the NOTIFY to UE B* 


\ 


39 


200 OK 


UE B responds to the NOTIFY with a 200 OK 




40 


200 OK 


IMS A forwards the 200 OK to IMS B 




41 




i 










User B is informed about successful registration 
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4.5.2.7 



First time registration in a visited IMS network requiring Topology Hiding 



Interoperability Test Description 


Identifier: 


TD IMS 0008 


Summary: 


First time registration via a visited IIVIS network with topology hiding 


Configuration: 


CF ROAM REG 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5134 01 


clause 5.10.4.1 §5 


IP IMS 5401 01 


clause 5.10.2.1 §1 


TP IMS 5405 01 


clause 5.10.2.2 §1 


Use Case ref.: 


UC 01 R 


1^^^ 


Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• UE_B is not registered 

• IMS A has topology hiding enabled 


J 


Test Sequence: 


Step 


J 


1 


User B registers in IMS B using any user identity 


2 


Verify that UE B shows successful registration 


r ^1^ I 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5134_01 in CFW step 3, 7 (REGISTER): 
ensure that { 
when { UE B sends a REGISTER to IMS A } 
then { IMS_A sends the REGISTER to IMS_B 

containing an additional topmost Path header 
indicating the IBCF SIP URI of IMS A } 
} 


2 


TP_IMS_5401_01 in CFW step 3, 7 (REGISTER): 
ensure that { 
when { UE_B sends a REGISTER to IMS_A 

containing Path header} 
then { IMS_A sends the REGISTER to IMS_B 
containing a Path_header 

containing (encrypted_consecutive_header_entries and 
tokenized-by parameter) } 
} 


3 


TP_IMS_5405_01 in CFW step 10, 15 (SUBSCRIBE): 
ensure that { 
when { UE B sends a SUBSCRIBE to IMS B } 
then { IMS_A sends the SUBSCRIBE to IMS_B 
containing a Via_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-byjDarameter) and 
containing a Record- Route_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by jDarameter) and 
containing a Route_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
not containing (a P-Charging-Vector_header and 

a P-Charging-Function-Addresses header) } 
} 
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Step 


Direction 


IVIessage 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 














1 














User B registers in IIVIS B 


^ 


2 








X 




REGISTER 


UE B sends a REGISTER to IMS A 


• 


3 


REGISTER 


IMS A forwards the REGISTER to IMS B 


f 


4 


401 Unauthorized 


IIVIS B responds with 401 Unauthorized to 
IMS A 




5 


401 Unauthorized 


IMS A forwards the 401 Unauthorized to UE B 


X 


6 


REGISTER 


UE_B sends the same REGISTER containing 
authentication challenge response to IMS A 


{ 


7 


REGISTER 


IMS A forwards the REGISTER to IMS B 


^ 


8 


200 OK 


IMS B responds with 200 OK 


\ 


9 


200 OK 


IMS A forwards the 200 OK response to UE B 


X 


10 


SUBSCRIBE 


IMS A sends a SUBSCRIBE to IMS B 


• 


11 


200 OK 


IMS B responds with a 200 OK 


f 


12 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 




13 


200 OK 


IMS_A responds to the NOTIFY with a 200 OK 


X 


14 


SUBSCRIBE 


UE_B sends a SUBSCRIBE (reg event 
package) to IMS A 


• 


15 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE request to 
IMS B 


z' 


16 


200 OK 


IMS B responds to the SUBSCRIBE with a 200 
OK 


^ 


17 


200 OK 


IMS A forwards the 200 OK response to UE B 


< 


18 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 


X 


19 


NOTIFY 


IMS A forwards the NOTIFY to UE B 


X 


20 


200 OK 


UE B responds to the NOTIFY with a 200 OK 




21 


200 OK 


IMS A forwards the 200 OK to IMS B 




22 














User B is informed about successful registration 
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4.5.3 Initial Dialog or Standalone Procedures 



4.5.3.1 



Initial INVITE Dialog Procedures 



4.5.3.1.1 



Initial INVITE Request Procedures - Originating 



4.5.3.1.1.1 



Default SIP URI 



Interoperability Test Description 


Identifier: 


ID IMS 0009 


Summary: 


Ensure that the IMS network can handle establishment of dialogs for users with default 
SIP URIs and resolve Tel URI E.163 numbers 


Configuration: 


CF INT CALL 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5097 01 


clause 5.4.3.2 §1 


TP IMS 5097 02 


clause 5.4.3.2 §1 


TP IMS 5097 04 


clause 5.4.3.2 §1 


TP IMS 5107 02 


clause 5.4.3.2 §49 


TP IMS 5107 01 


clause 5.4.3.2 §49 


TP IMS 5115 01 


clause 5.4.3.3 §39 


TP IMS 5115 03 


clause 5.4.3.3 §39 


TP IMS 5115 02 


clause 5.4.3.3 §39 


TP IMS 5115 04 


clause 5.4.3.3 §39 


TP IMS 5131 01 


clause 5.3.2.1 §37 


TP IMS 5131 02 


clause 5.3.2.1 §37 


Use Case ref.: 


UC 02 1 


I^^H. J 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A as user2 according to table 1 

• UE_B is registered in IMS_B as user2 according to table 1 

• IMS_A within the trust domain of IMS_B 

• DNS B configured with an ENUM entry for the Tel URI E.I 64 Number of user 
2 privoflMS B 


Test Sequence: 


Step 




1 


User A calls user B's Tel URI 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers the call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that the call is established 


7 


User A ends the call 


8 


Verify with UE B that call has been released 


9 


Verify with UE A that call has been released 




Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_01 in GFW step 4 (INVITE): 
ensure that { 

when { UE_A sends an initial INVITE to UE_B } 
then { IMS_B receives the initial INVITE 
not containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a P-Charging-Vector_header 
(containing an icid_parameter and 
containing a orig-ioi_parameter indicating IMS_A and 
not containing a term-ioi_parameter) and 
containing a Record-Route_header 

indicating the originating S-CSCF_SIP_URI and 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo_header } 
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Interoperability Test Description 



L 



TP_IMS_5097_02 in CFW step 4 (INVITE): 
ensure that { 
when { UE_A sends an initial INVITE to UE_B 

not containing a P -Preferred- Identity _header or 
containing a P-Preferred-ldentity_header 
not indicating a Tel_URI of UE_A} 
then { IMS_B receives the initial INVITE 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity of UE_A 
and 

containing a P- Asserted- ldentity_header 
indicating a Tel_URI of UE_A } 
L 



TP_IMS_5097_04 in CFW step 4 (INVITE): 
ensure that { 
when { UE_A sends an initial INVITE to UE_B 
containing a Request_URI 
indicating a Tel_URI} 
then { IMS_A sends a DNS_Query to DNS_B 

containing the Tel_URI_E. 164_Number} 
when { IMS_A receives DNS_Response 

containing a NAPTR_Resource_Record 
indicating the SIP_URI of UE_B } 
then { IMS_A sends the initial INVITE to IMS_B 
containing a Request_URI 

indicating the SIP_URI of UE_B 
containing a P-Charging-Vector_header 
not containing a access-network-charging-info_parameter} 

L 



TP_IMS_5107_02 in CFW step 19 (ACK): 
ensure that { 
when { UE_A sends ACK to UE_B } 
then { IMS_B receives the ACK 

not containing Route_header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo_header } 

1 



TP_IMS_5107_01 in CFW step 24A (BYE): 
ensure that { 
when { UE_A sends BYE to UE_B } 
then { IMS_B receives the BYE 

containing no Route_header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo_header } 
1 



TP_IMS_5115_01 in CFW step 10 (180 Ringing): 
ensure that { 
when { UE_B sends a 180_response to UE_A } 
then { IMS_A receives the 180_response from IMS_B 
containing a P-Charging-Vector_header 
containing a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operatorjdentifier of IMS_B 

_j 
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Interoperability Test Description 



10 



11 



TP_IMS_5115_03 in CFW step 10 (180 Ringing): 
ensure that { 
when { UE_B sends a 1xx_response to UE_A 

(not containing a P- Preferred- ldentity_heacler or 
containing a P-Preferred-ldentity_header 
indicating a SIP_URI of UE_B) } 
then { IMS_A receives the 1xx_response from IMS_B 
containing a P- Asserted- ldentity_header 

indicating the default_registered_public_identity and 
containing a P- Asserted- ldentity_header 
indicating a Tel_URI of UE_BI } 
1 



TP_IMS_51 15_02 in CFW step 15 (2xx): 
ensure that { 
when { UE_B sends a 2xx_response to UE_A } 
then { li\/IS_A receives the 2xx_response from li\/IS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operatorjdentifier of ll\/IS_A and 
containing a term-ioi_parameter 
indicating operatorjdentifier of IMS_B 

L 



TP_IMS_51 15_04 in CFW step 15 (2xx): 
ensure that { 
when { UE_B sends a 2xx_response to UE_A 

(not containing a P-Preferred-ldentity_header or 
containing a P- Preferred- ldentity_header 
not indicating a Tel_URI of UE_B) } 
then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Asserted-ldentity_header 

indicating the defauit_registered_pubiic_identity of UE_B and 
containing a P- Asserted- ldentity_header 
indicating a Tel_URI of UE_B} 
1 



TP_IMS_5131_01 in CFW step 10 (180 Ringing): 
ensure that { 

when { UE_B sends a 180_response to UE_A } 

then { IMS_B sends the 180_response to ll\/IS_A 

not containing a P-Charging-Function-Addresses_header} 

1 



TP_IMS_5131_01 in CFW step 15 (2xx) 
ensure that { 
when { UE_B sends a 2xx_response to UE_A } 
then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operatorjdentifier of ll\/IS_A and 
containing a term-ioi_parameter 
indicating operatorjdentifier of ll\/IS_B 
} 
1 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














1 


















User A calls User B 


^ 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 




3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B 


f 


7 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




8 












^ 






User B is informed of incoming call of User A 


9 






/^ 


f 


^ 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 


\ 


10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 




12 




i 














User A is informed that UE B is ringing 


13 






User B answers call 


k 


14 








f 


• 






200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




15 


200 OK 


IMS B forwards 200 OK response to IMS A 




16 


200 OK 


IMS A forwards the 200 OK response to UE A 




17 




i 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS 




20 


ACK 


IMS B forwards ACK to UE B 




21 












^ 






User B is informed that the call is established 


22A 






User A ends call 


^ 


23A 
















BYE 


UE A releases the call with BYE 




24A 


BYE 


IMS A forwards BYE to IMS B 




25A 


BYE 


IMS B forwards BYE to UE B 




26A 












^ 






User B is informed that call has ended 


27A 






f 


{ 


^ 






200 OK 


UE B sends 200 OK for BYE 


\ 


28A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




29A 


200 OK 


IMS A forwards the 200 OK response to UE A 




30A 












^ 






User B is informed that call has ended 
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4.5.3.1.1.2 



Default Tel URI 



Interoperability Test Description 


Identifier: 


ID IMS 0010 


Summary: 


Ensure that the IMS network can handle establishment of dialogs for users with default 
TEL URIs 


Configuration: 


CF INT CALL 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5097 01 


clause 5.4.3.2 §1 


TP IMS 5097 03 


clause 5.4.3.2 §1 


TP IMS 5107 02 


clause 5.4.3.2 §49 


TP IMS 5107 01 


clause 5.4.3.2 §49 


TP IMS 5115 01 


clause 5.4.3.3 §39 


TP IMS 5115 05 


clause 5.4.3.3 §39 


TP IMS 5115 02 


clause 5.4.3.3 §39 


TP IMS 5115 06 


clause 5.4.3.3 §39 


TP IMS 5131 01 


clause 5.4.3.3 §37 


TP IMS 5131 02 


clause 5.3.2.1 §37 


Use Case ref.: 


UG 02 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using user3 according to table 1 

• UE_B is registered in IMS_B using user3 according to table 1 

• IMS A within the trust domain of IMS B 


^m ■ 


Test Sequence: 


Step 


J 


1 


User A calls user B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers the call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that the call is established 


7 


User A ends the call 


8 


Verify with UE B that call has been released 


^^^ 


Verify with UE A that call has been released 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_01 in GFW step 4 (INVITE): 
ensure that { 

when { UE_A sends an initial INVITE to UE_B } 
then { IMS_B receives the initial INVITE 
not containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a P-Charging-Vector_header 
(containing an icid_parameter and 
containing a orig-ioi_parameter indicating IMS_A and 
not containing a term-ioi_parameter) and 
containing a Record-Route_header 

indicating the originating S-CSCF_SIP_URI and 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo header} 
} 
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Interoperability Test Description 



TP_IMS_5097_03 in CFW step 4 (INVITE) 
ensure that { 
when { UE_A sends an initial INVITE to UE_B 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI of UE_A } 
then { IMS_B receives the initial INVITE 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity of UE_A 
and 

containing a P-Asserted-ldentity_header 
indicating a Tel_derived_SIP_URI of UE_A} 
L 



TP_IMS_5107_02 in CFW step 19 (ACK): 
ensure that { 
when { UE_A sends ACK to UE_B } 
then { IMS_B receives the ACK 

not containing Route_header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo_header } 

L 



TP_IMS_5107_01 in CFW step 24A (BYE): 
ensure that { 
when { UE_A sends BYE to UE_B } 
then { IMS_B receives the BYE 

containing no Route_header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo_header } 

1 



TP_IMS_5115_01 in CFW step 10 (180 Ringing): 
ensure that { 
when { UE_B sends a 180_response to UE_A } 
then { IMS_A receives the 180_response from IMS_B 
containing a P-Charging-Vector_header 
containing a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operatorjdentifier of IMS_B 



TP_IMS_5115_05 in CFW step 10 (180 Ringing): 
ensure that { 
when { UE_B sends a 1xx_response to UE_A 

(not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI) } 
then { IMS_A receives the 1xx_response 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel_derived_SIP_URI } 

L 



TP_IMS_51 15_02 in CFW step 15 (2xx): 
ensure that { 
when { UE_B sends a 2xx_response to UE_A } 
then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operatorjdentifier of IMS_B 
J 
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Interoperability Test Description 




8 


TP_IMS_5115_06 in CFW step 15 (2xx): 
ensure that { 
when { UE_B sends a 2xx_response to UE_A 

(not containing a P- Preferred- ldentity_heacler or 
containing a P-Preferred-ldentity_header 
indicating a Tei_URI) } 
then { IMS_A receives the 2xx_response 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel derived SIP URI } 
} 


9 


TP_IMS_5131_01 in CFW step 10 (180 Ringing): 
ensure that { 

when { UE_B sends a 180_response to UE_A } 

then { IMS_B sends the 180_response to IMS_A 

not containing a P-Charging-Function-Addresses header} 
} 


10 


TP_IMS_5131_01 in CFW step 15 (2xx) 
ensure that { 
when { UE_B sends a 2xx_response to UE_A } 
then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B 
} 
} 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














1 


















User A calls User B 


^ 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 




3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B 


f 


7 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




8 












^ 






User B is informed of incoming call of User A 


9 






/^ 


f 


^ 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 


\ 


10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 




12 




i 














User A is informed that UE B is ringing 


13 






User B answers call 


k 


14 








f 


• 






200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




15 


200 OK 


IMS B forwards 200 OK response to IMS A 




16 


200 OK 


IMS A forwards the 200 OK response to UE A 




17 




i 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 




20 


ACK 


IMS B forwards ACK to UE B 




21 












^ 






User B is informed that the call is established 


22A 


















User A ends call 




23A 


BYE 


UE A releases the call with BYE 




24A 


BYE 


IMS A forwards BYE to IMS B 




25A 


BYE 


IMS B forwards BYE to UE B 




26A 












^ 






User B is informed that call has ended 


27A 






f 


{ 


^ 






200 OK 


UE B sends 200 OK for BYE 


\ 


28A 


200 OK 


IMS_B forwards 200 OK response to IMS_ 




29A 


200 OK 


IMS A forwards the 200 OK response to UE A 




30A 












^ 






User B is informed that call has ended 
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4.5.3.1.1.3 



Rejection of call from barred user 



Interoperability Test Description 


Identifier: 


ID IMS 0011 


Summary: 


Ensure that IIVIS does not establish call for barred user 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5097 11 


clause 5.4.3.2 §1 


Use Case ref.: 


UG_02_I 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• IMS_A within the trust domain of IMS_B 

• User B has been barred in IMS B 


Test Sequence: 


Step 




1 


User A calls user B 


2 


Verify that user A is informed that call cannot be established 


II 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_1 1 in GFW step 4 (INVITE): 
ensure that { 
when { UE A sends an initial INVITE to UE B and 
IMS_A sends the INVITE to IMS_B 
containing a P -Asserted- ldentity_header 
indicating a barred_user in IMS_B } 
then { IMS B sends 403 response to IMS A } 
} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 


















1 Icpr A ppIIq I iQPr R 


2 




^ 












INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 


/^ 


3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


{ 


4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


403 
forbidden 


IMS_B responds to the INVITE with 403 
Forbidden 




7 

Q 


403 
Forbidden 


IMS B responds to the 403 Forbidden response 
toUE A 




O 

9 
















ACK 


user A IS inTormeo inai can nas Taiieo 
UE A acknowledges the response 




10 


ACK 


IMS A forwards the ACK to IMS B 
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4.5.3.1.1.4 



Rejection of call to non-existing user 



Interoperability Test Description 


Identifier: 


ID IMS 0012 


Summary: 


Ensure that IMS rejects call to non existing user 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5132 01 


clause 5.3.2.1 §28 


Use Case ref.: 


UG_01_I 


Pre-test 
conditions: 


• HSS of IMS_A and is configured according to table 1 

• UE_A have IP bearers established to their respective IMS networks as per 
clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• IMS A within the trust domain of IMS B 




Test Sequence: 


Step 


i 


1 


User A calls user B indicating a non existing identity within IMS B domain 


^^^^^H 


2 


Verify that user A is informed that call cannot be established 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5132_01 in GFW step 6 (404 Not Found): 
ensure that { 
when { UE_A sends an initial INVITE 
containing a Request_URI 
indicating a non existing user in IMS B and 
IMS_A sends the INVITE to IMS_B } 
then { IMS B sends an appropriate (e.g. 404 or 604) to IMS A } 

} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 














1 


















User A calls User B 


^ 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs 
that UE_A supports 




3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


< 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


< 


6 


404 Not 
Found 


IMS B responds with 404 Not Found to 
IMS A 




7 


404 Not 
Found 


IMS A forwards the 404 Not Found response to 
UE A 




8 


















User A is informed that called user does not 
exist 


i 




9 
















ACK 


UE_A acknowledges the receipt of a 404 final 
response 




10 


ACK 


IMS A forwards the ACK to IMS B 
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4.5.3.1.1.5 



Rejection of call to unavailable user 



Interoperability Test Description 


Identifier: 


ID IMS 0013 


Summary: 


Ensure that IMS does not establish a call for unavailable user 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5133 01 


clause 5.3.2.1 §29 


Use Case ref.: 


UG_01._I 


Pre-test 
conditions: 


• HSS of IMS_A and IMS_B is configured according to table 1 

• UE_A has IP bearers established to their respective IMS networks as per 
clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE B is not registered in IMS B 




Test Sequence: 


Step 




1 


User A calls a valid user B identity 


2 


Verify that user A is informed that user B is not reachable or equivalent 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5133_01 in GFW step 6 (4xx): 

ensure that { 
when { UE_A sends INVITE to UE_B } 
then { IMS B sends a 4xx response to IMS A } 

} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 














1 


















User A calls User B 


^ 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 




3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


K 


4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


/^ 


6 


4xx 


IMS B responds with 4xx to IMS A 




7 


4xx 


IMS A forwards the 4xx response to UE A 




8 


















User A is informed that called user does not 
exist 


i 




9 
















ACK 


UE_A acknowledges the receipt of a 404 final 
response 




10 


ACK 


IMS A forwards the ACK to IMS B 
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4.5.3.1.2 



Dialogue Procedures with Roaming 



4.5.3.1.2.1 



Normal call 



Interoperability Test Description 


Identifier: 


TD IMS 0014 


Summary: 


Normal call while UE B is roaming without topology hiding 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5046 01 


clause 5.2.6.3 §4 


TP IMS 5067 01 


clause 5.2.7.2 §7 


TP IMS 5070 01 


clause 5.2.7.3 §6 


TP IMS 5301 01 


clause 5.4.3.3 §56 


TP IMS 5055 01 


clause 5.2.6.4 §15 


TP IMS 5055 02 


clause 5.2.6.4 §15 


TP IMS 5108 01 


clause 5.4.3.3 §1 


Use Case ref.: 


UG 02 R 


^m -^^ 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to IMS_B as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B via IMS_A using any user identity 

• IMS_A within the trust domain of IMS_B 

• A Service-Route header list exists for UE B in P-CSCF 


^^ ■ 


Test Sequence: 


Step 


J 


1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE_B is ringing 


4 


User B answers call 


5 


Verify that User A is informed that call has been answered 


6 


Verify that User B is informed that the call is established 


7 


User A ends call 


8 


Verify that user B is informed that call has ended 


^^^^ 


Verify that user A is informed that call has ended 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5046_01 in GFW step 4 
ensure that { 
when { IMS A receives an initial INVITE from UE Bj 
then { IMS_A sends the INVITE to IMS_B 
containing an additional Via_header 
containing ( the P-CSCF_via_port_number and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
containing an additional topmost Record-Route_header 
indicating (the P-CSCF_port_number 

'where it awaits subsequent requests' from UE A and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
indicating the 'list of Service Route header URIs 
from the registration' and 
not containing P- Preferred- ldentity_header and 
containing a P-Asserted-ldentity_header 

containing an address of UE_A and 
containing a P-Charging-Vector_header 
containing an icid parameter} 
} 
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Interoperability Test Description 



TP_IMS_5067_01 in CFW step 4 
ensure that { 
when { IMS_A receives an initial INVITE from UE_B } 
then { IMS_A sends the INVITE to IMS_B 

containing a P-Charging-Vector_header 
containing a access-network-charging-info_parameter 



L 



} 



TP_IMS_5070_01 in CFW step 7 

ensure that { 
when { IMS_A receives an initial INVITE from UE_B } 
then { IMS_A sends a 100_response to IMS_B 



L 



} 



TP_IMS_5301_01 in CFW step 29A 
ensure that { 
when { IMS_A receives a BYE from UE_A 

} 
then { IMS_A sends the BYE 

containing no Route_header 

indicating the S-CSCF_SIP_URI of IMS_A 

containing a topmost Record-Route_header 

indicating the S-CSCF_SIP_URI of IMS_A 



L 



} 



TP_IMS_5055_01 in CFW step 12 
ensure that { 
when { IMS_A receives a 180_response from UE_B} 
then { IMS_A sends a 180_response to IMS_B 
containing a Record- Route_header 
containing the P-CSCF_port_number of IMS_A 

'where it expects subsequent requests' and 
not containing a comp_parameter and 
not containing a P-Preferred-ldentity_header and 
containing a P-Asserted-ldentity_header 
indicating the address 'sent in P-Called_Party-ID header 
sent in the initial request'} 
1 



TP_IMS_5055_02 in CFW step 18 
ensure that { 
when { IMS_A receives a 200_response from UE_B } 
then { IMS_A sends the 200_response to IMS_B 
containing a Record- Route_header 
containing the P-CSCF_port_number of IMS_A 

'where it expects subsequent requests' and 
not containing a comp_parameter and 
not containing a P-Preferred-ldentity_header and 
containing a P- Asserted- ldentity_header 
indicating the address 'sent in P-Called_Party-ID header 
sent in the initial request' 



L 



} 



TP_IMS_5108_01 in CFW step 6 (INVITE): 
ensure that { 
when { UE_A sends an initial INVITE to UE_B 
IMS_A sends the INVITE to IMS_B 
containing a P-Charging-Vector_header 
containing an icid_parameter } 
then { IMS_B sends the INVITE to IMS_A 
containing no Route_header 

indicating the S-CSCF_SIP_URI of IMS_B and 
containing a P-Charging-Vector_header 
containing the same icid_parameter and 
not containing ioi_parameters 
containing a Record-Route_header 
containing the S-CSCF_SIP_URI of IMS_B } 
1 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 














1 


















User B calls User A 


^ 


2 






< 










INVITE 


UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE B supports 


< 


3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


f 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards the INVITE to IMS A 




7 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




8 


INVITE 


IMS A forwards the INVITE to UE A 








9 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








10 




i 














User A is informed of incoming call of User B 


11 
















180 Ringing 


UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 






y 


12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 




13 


180 Ringing 


IMS B forwards the 180 Ringing response to 
IMS A 




14 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE B 


K 


15 








i 










User B is informed that UE A is ringing 


16 






User A answers call 


^ 


17 
















200 OK 


UE_A responds INVITE with 200 OK to indicate 
that the call has been answered 






{ 


18 


200 OK 


IMS A forwards 200 OK response to IMS B 
S 




19 


200 OK 


IMS B forwards the 200 OK response to IMS A 


\ 


20 


200 OK 


IMS_A forwards the 200 OK response to UE_B 




21 








i 










User B is presented that call in process 


22 






/^ 










ACK 


UE B acknowledges the receipt of 200 OK for 
INVITE 




23 


ACK 


IMS A forwards ACK to IMS B 


{ 


24 


ACK 


IMS B forwards ACK to IMS A 




25 


ACK 


IMS A forwards ACK to UE A 








26 




i 














User A is informed that the call is in progress 


27A 






User A ends call 


— > 


28A 
















BYE 


UE A releases the call with BYE 






• 


29A 


BYE 


IMS A forwards BYE to IMS B 


f 


30A 


BYE 


IMS B forwards BYE to IMS A 




31A 


BYE 


IMS A forwards BYE to UE B 




32A 








i 










User B is informed that call has ended 
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4.5.3.1.2.2 



Normal call with hold/resume 



Interoperability Test Description 


Identifier: 


ID IMS 0015 


Summary: 


Check that subsequent INVITEs are handled correctly In case of a user initiated call 
hold and resume when home caller puts roaming user on hold and resumes call 


Configuration: 


OF ROAM GALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5081 01 


clause 5.2.9.2 §1 


IP IMS 5082 01 


clause 5.2.9.2 §2 


IP IMS 5120 01 


clause 5.4.3.3 §48 


Use Case ref.i 


UC 03 R 


^^ ■ 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using INVITE 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B via IMS A using any user identity 


■I 


Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 


Jl 


Conformance 
Criteria: 


Check 


i 


1 


TP_IMS_5081_01 in GFW step 41 A and 60A (100 Trying): 
ensure that { 

when { UE A sends a subsequent INVITE to UE B and 
IMS_A receives the INVITE from IMS_B } 

then { IMS A sends a 100 response to IMS 8} 
} 


2 


TP_IMS_5082_01 in GFW step 46A and 65A (200 OK): 
ensure that { 
when { IMS_A receives a 200_response from UE_B } 
then { IMS_A sends the 200_response to IMS_B 
containing a P-Charging-Vector_header 
containing an updated 

access-network-charging-info parameter 
} 
} 


3 


TP_IMS_5120_01 in GFW step 40A and 59A (INVITE): 
ensure that { 

when {UE A sends a subsequent INVITE to UE 3} 
then { IMS_A receives the INVITE from IMS_B 

not containing a topmost Route_header 

containing the S-CSCF_SIP_URI 
containing a Record- Route_header 
containing the S-CSCF SIP URIj 
} 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 














34 


















User B is presented that call is in progress 


i 


35A 






User A puts call on hold 


^ 


36A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 








37A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 






y 


38A 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


39A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




40A 


INVITE 


IMS B forwards INVITE to IMS A 


\ 


41 A 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




42A 


INVITE 


IMS A forwards INVITE to UE B 




43A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




44A 








i 










User B is informed that call is on hold 


45A 






< 










200 OK 


UE_B responds to INVITE with 200 OK 
indicating attribute "recvonly" inactive 




46A 


200 OK 


IMS A forwards 200 OK response to IMS B 




47A 


200 OK 


IMS B forwards 200 OK response to IMS A 




48A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








49A 


ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 






{ 


50A 


ACK 


IMS A forwards ACK to IMS B 




51A 


ACK 


IMS B forwards ACK to IMS A 




52A 


ACK 


IMS A forwards ACK to UE B 




53A 




i 














User A is informed that call is on hold 


54A 






User A resumes call 


^ 


55A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 


/^ 






56A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 






y 


57A 


INVITE 


IMS A forwards INVITE to IMS B 




58A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




59A 


INVITE 


IMS B forwards INVITE to IMS A 




60A 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




61A 


INVITE 


IMS A forwards INVITE to UE B 


\ 


62A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




63A 








i 










User B is informed that call is resumed 


64A 
















200 OK 


UE_B responds to INVITE with 200 OK 
indicating media attribute "sendrecv" 




65A 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


f 


66A 


200 OK 


IMS B forwards 200 OK response to IMS A 




67A 


200 OK 


IMS A forwards the 200 OK response to UE A 








68A 




i 














User A is informed that call is resumed 
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4.5.3.1.2.3 



Subsequent request (other than target refresh) 



Interoperability Test Description 


Identifier: 


ID IMS 0016 


Summary: 


Check that the P-GSGF, after a dialogue has been established, modifies routing 
information in subsequent requests (other than target refresh) received from the UE 
before forwarding them to an IMS. 


Configuration: 


OF ROAM GALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5052 01 


clause 5.2.6.3 §56 


Use Case ref.: 


UG 02 R 


I^V -^^ 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_B has IP bearers established to their respective IMS networks as per 
clause 4.2.1 

• UE_A registered in IMS_A using any user identity 

• UE B is registered in IMS B via IMS A using any user identity 


p ^^ 1 


Test Sequence: 


Step 




1 


User B calls user A 


2 


Verify that user A is informed of incoming call of User B 


3 


Verify that user B is informed that UE A is ringing 


4 


User A answers call 


5 


Verify that user B is informed that call has been answered 


6 


Verify that user A is informed that call is established 


7 


User B ends call 


8 


Verify that user A is informed that call has ended 




9 


Verify that user B is informed that call has ended 


J 


Conformance 
Criteria: 


Check 


J 


1 


TP_IMS_5052_01 in GFW step 29B (BYE): 
ensure that { 
when { IMS_A receives a BYE from UE_B } 
then { IMS_A sends the BYE to IMS_B 
not containing a Route_header 

indicating the P-CSCF_SIP_URI of ll\/IS_A and 
containing the same Record-Route_header 
as in the previous ACK 
} 
} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 














27B 


















User B ends call 


^ 


28B 






< 










BYE 


UE B releases the call with BYE 




29B 


BYE 


IMS A forwards BYE to IMS B 




SOB 


BYE 


IMS B forwards BYE to IMS A 




31B 


BYE 


IMS A forwards BYE to UE A 








32B 




i 














User A is informed that call has ended 
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4.5.3.1.2.4 



Subsequent target refresh request (INVITE) 



Interoperability Test Description 


Identifier: 


TD IMS 0017 


Summary: 


Check that subsequent INVITEs are handled correctly In case of a user initiated call 
hold and resume when roaming caller puts a home user on hold and resumes call 


Configuration: 


OF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5048 01 


clause 5.2.6.3 §26 


IP IMS 5080 01 


clause 5.2.9.1 §2 


Use Case ref.: 


UC 03 R 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_B configured to perform user initiated hold/resume using INVITE 

• UE_A registered in IMS_A using any user identity 

• UE B is registered in IMS B via IMS A using any user identity 




Test Sequence: 


Step 


J 


1 


User B calls User A 


2 


Verify that user A is informed of incoming call of User B 


3 


Verify that user B is informed that UE A is ringing 


4 


User A answers call 


5 


Verify that user B is informed that call has been answered 


6 


Verify that user A is informed that call is established 


7 


User B puts call on hold 


8 


Verify that user A is informed that call is on hold 


9 


Verify that user B is informed that call is on hold 


10 


User B resumes call 


11 


Verify that user A is informed that call is resumed 


12 


Verify that user B is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 






Conformance 
Criteria: 


Check 




1 


TP_IMS_5048_01 in CFW step 38B and 57B (INVITE): 
ensure that { 
when { IMS A receives a subsequent INVITE from UE B } 
then { IMS_A sends the INVITE to IMS_B 

containing an additional topmost Record-Route_header 
containing ( the P-CSCF_port_number 'where it awaits 
subsequent requests' from UE A and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
containing an additional Via_header 
containing ( the P-CSCF_via_port_number and 
(the P-CSCF-FQDN address or 
theP-CSCF-IP address)) of IMS A} 
} 


2 


TP_IMS_5080_01 in CFW step 38B and 57B (INVITE): 
ensure that { 
when { IMS A receives subsequent INVITE from UE B } 
then { IMS_A sends the INVITE to IMS_B 
containing a P-Charging-Vector_header 

containing an updated access-network-charging-info parameter} 
} 
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Step 


Direction 


IVIessage 


Comment 
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B 














35B 


















User B puts call on hold 


^ 


36B 






/^ 










INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 


f 


37B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




38B 


INVITE 


IMS A forwards INVITE to IMS B 




39B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




40B 


INVITE 


IMS B forwards INVITE to IMS A 




41 B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




42B 


INVITE 


IMS A forwards INVITE to UE A 








43B 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








44B 




i 














User A is informed that call is on hold 


45B 
















200 OK 


UE_A responds to INVITE with 200 OK 
indicating attribute "recvonly" 






• 


46B 


200 OK 


IMS A forwards 200 OK response to IMS B 


f 


47B 


200 OK 


IMS B forwards 200 OK response to IMS A 




48B 


200 OK 


IMS A forwards the 200 OK response to UE B 




49B 


ACK 


UE B acknowledges the receipt of 200 OK for 
INVITE 




SOB 


ACK 


IMS A forwards ACK to IMS B 


f 


51B 


ACK 


IMS B forwards ACK to IMS B 




52B 


ACK 


IMS A forwards ACK to UE A 








53B 








k 










User B is informed that call is on hold 


54B 






User B resumes call 


^ 


55B 






{ 










INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 


{ 


56B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




57B 


INVITE 


IMS A forwards INVITE to IMS B 


f 


58B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




59B 


INVITE 


IMS B forwards INVITE to IMS A 




60B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




61B 


INVITE 


IMS A forwards INVITE to UE A 








62B 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








63B 




i 














User A is informed that call is resumed 
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4.5.3.1.2.5 



Subsequent target refresh request (UPDATE), roaming user initiated 



Interoperability Test Description 


Identifier: 


TD IMS 0018 


Summary: 


Check that subsequent UPDATES are handled correctly In case of a user initiated call 
hold and resume when roaming caller puts a home user on hold and resumes call 


Configuration: 


CF ROAM GALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5080 02 


clause 5.2.9.1 §2 


Use Case ref.: 


UG 03 R 


^^^^^^^^^1 


^■— 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_B has IP bearers established to their respective IMS networks as per 
clause 4.2.1 

• UE_A registered in IMS_A 

• UE_B configured to perform user initiated hold/resume using UPDATE 

• UE_B is registered in IMS B via IMS A 


Test Sequence: 


Step 


1 — '^^^" ^^^ ■ 


1 


User B calls User A 


2 


Verify that user A is informed of incoming call of User A 


3 


Verify that user B is informed that UE A is ringing 


4 


User A answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User B puts call on hold 


8 


Verify that user A is informed that call is on hold 


9 


Verify that user B is informed that call is on hold 


10 


User B resumes call 


11 


Verify that user A is informed that call is resumed 


12 


Verify that user B is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 




Conformance 
Criteria: 


Check 


J 


1 




1 


TP_IMS_5080_02 in GFW step 37B and 47B (UPDATE): 
ensure that { 
when { IMS A receives subsequent UPDATE from UE B } 
then { IMS_A sends the UPDATE to IMS_B 
containing a P-Charging-Vector_header 

containing an updated access-network-charging-info parameter} 
} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


































35B 








^ 










User B puts call on hold 


36B 
















UPDATE 


UE_B sends UPDATE message indicating 
media attribute "sendonly" (Gall Hold) 




37B 


UPDATE 


IMS_A forwards UPDATE to IMS_B 


/^ 


38B 


UPDATE 


IMS B forwards UPDATE to IMS A 




39B 


UPDATE 


IMS A forwards UPDATE to UE A 


K 






40B 




i 














User A is informed that call on hold 


41 B 
















200 OK 


UE_A responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 








42B 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




43B 


200 OK 


IMS B forwards 200 OK response to IMS A 


K 





ETSI 



83 



ETSI TS 186 011-2 V2.1.1 (2009-02) 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 






44B 










y 






200 OK 


IMS A forwards the 200 OK response to UE B 


K 


45B 








^ 










User B resumes call 


46B 






< 










UPDATE 


UE_B sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 




47B 


UPDATE 


IIVIS A forwards UPDATE to IIVIS B 




48B 


UPDATE 


IMS B forwards UPDATE to IMS A 


K 


49B 


UPDATE 


IMS A forwards UPDATE to UE A 








SOB 




i 














User A is informed that call is resumed 



4.5.3.1.2.6 



Subsequent target refresh request (UPDATE), home user initiated 



Interoperability Test Description 


Identifier: 


TD IMS 0019 


Summary: 


Check that subsequent UPDATES are handled correctly In case of a user initiated call 
hold and resume when home caller puts a roaming user on hold and resumes call 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5120 02 


clause 5.4.3.3 §48 


Use Case ref.: 


UC 03 R 


Jl 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using UPDATE 

• UE_A registered in IMS_A using any user identity 

• UE B is registered in IMS B via IMS A using any user identity 




Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 




Conformance 
Criteria: 


Check 




1 


TP_IMS_5120_02 in CFW step 38A and 49A (UPDATE): 
ensure that { 

when { UE A sends an UPDATE to UE B } 
then { IMS_A receives the UPDATE from IMS_B 
not containing a topmost Route_header 

containing the S-CSCF_SIP_URI 
containing a Record- Route_header 
containing the S-CSCF SIP URI } 
} 



[Step 



Direction 



Message 



Comment 
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U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 














35A 


















User A puts call on hold 


^ 


36A 
















UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 






y 


37A 


UPDATE 


IMS A forwards UPDATE to IMS B 


< 


38A 


UPDATE 


IMS B forwards UPDATE to IMS A 




39A 


UPDATE 


IMS A forwards UPDATE to UE B 


K 


40A 








i 










User B is informed that call is on hold 


41A 






< 










200 OK 


UE_B responds to with 200 OK indicating media 
attribute "recvonly" 




42A 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




43A 


200 OK 


IMS B forwards 200 OK response to IMS A 


K 


44A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








45A 




i 














User A is informed that call is on hold 


46A 






User A resumes call 


^ 


47A 
















UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 






y 


48A 


UPDATE 


IMS A forwards UPDATE to IMS B 


f 


49A 


UPDATE 


IMS B forwards UPDATE to IMS A 




50A 


UPDATE 


IMS A forwards UPDATE to UE B 




51A 








i 










User B is informed that call is resumed 


52A 






/^ 










200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 




53A 


200 OK 


IMS A forwards 200 OK response to IMS B 




54A 


200 OK 


IMS B forwards 200 OK response to IMS A 




55A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








56A 




i 














User A is informed that call is resumed 
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4.5.3.1.2.7 



Call CANCEL due to loss of connectivity of calling user during call establishment 



Interoperability Test Description 


Identifier: 


ID IMS 0020 


Summary: 


IMS sends CANCEL to call originator in case terminating UE looses connectivity during 
dialog initiation 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5072 02 


clause 5.2.8.1.1 §1 


Use Case ref.: 


UC 02 R 


^^^^^^^^^1 


^"~ n 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B has IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A registered in IMS_A using any user identity 

• UE B is registered in IMS B via IMS A using any user identity 


l^^^^~ ■ 


Test Sequence: 


Step 


J 


1 


User B calls User A 


2 


Verify that user A is informed of incoming call of User B 


4 


Verify that user B is informed that UE_A is ringing 


5 


UE B loses connectivity to IMS A 


6 


Verify that user A is informed that call has been cancelled 


-■ 


Conformance 
Criteria: 


Check 








1 


TP_IMS_5072_02 in CFW step 18 (CANCEL): 
ensure that { 

when { IMS A receives 'an indication that UE B is no longer available' } 
then { IMS_A sends a CANCEL to IMS_B 
containing a Reason_header 
containing a status_code_parameter 
indicating '503 Service unavailable' 
} 
} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 














10 


















User A is informed of incoming call of User B 


i 


11 
















180 Ringing 


UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 






y 


12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 




13 


180 Ringing 


IMS B forwards the 180 Ringing response to 
IMS A 




14 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE B 


K 


15 








i 










User B is informed that UE A is ringing 


16 






UE B looses connectivity 


17 




IMS_A is informed about UE_B loosing 
connectivity 


18 
















CANCEL 


IMS A sends CANCEL to IMS B 


/^ 


19 


200 OK 


IMS B responds with 200 OK to IMS A 




20 


CANCEL 


IMS B forwards the CANCEL to IMS A 


K 


21 


200 OK 


IMS A responds with 200 OK to IMS B 




22 


CANCEL 


IMS A forwards the CANCEL to UE A 


K 






23 


200 OK 


UE A responds with 200 OK to IMS A 








24 




i 














User A is informed that call has been cancelled 


25 
















487 Request 
Terminated 


UE_A sends 487 Request Terminated to IMS_A 












y 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 






26 
















ACK 


IMS A responds with ACK to UE A 


K 






27 


487 Request 
Terminated 


IIVIS A forwards the 487 Request Terminated to 
IMS B 




28 


ACK 


IMS B responds with ACK to IMS A 





















4.5.3.1.3 



Subsequent Request Procedures - Originating Network 



4.5.3.1.3.1 



Call CANCEL by calling user 



Interoperability Test Description 


Identifier: 


TD IMS 0021 


Summary: 


Calling user cancels call before its establishment 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5107 3 


clause 5.4.3.2 §49 


Use Case ref.: 


UC 02 1 


^^^^^^^^^^^^^H 







Pre-test 
conditions: 



Test Sequence: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks 

as per clause 4.2.1 

UE_A is registered in IMS_A using any user identity 

UE_B is registered in IMS_B using any user identit\ 



Step 



User A calls User B 



! 



Verify that user B is informed of incoming call of User A 



Verify that user A is informed that UE_B is ringing 



User A cancels call 



Verify that user B is informed that call has been cancelled 



Conformance 
Criteria: 



Verify that user A is informed that call is terminated 



Check 



TP_IMS_5107_03 in CFW step 16 (CANCEL): 
ensure that { 
when { UE_A sends CANCEL to UE_B } 
then { IMS_B receives the CANCEL 
containing no Route_header 
indicating the S-CSCF_SIP_URI of IMS_B and 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo_header } 
1 



3 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


u 

s 
e 
r 
B 






1 


















1 Iqpt a ppiIIq I Iqpt R 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 




3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B 


f 


7 

Q 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




O 

9 






/^ 


f 


^ 






180 Ringing 


user b IS inTormeo ot incoming can ot user a 
UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 


\ 


10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 




12 
13 




i 














User A is informed that UE B is ringing 
User A cancels the call 


^ 


14 
















CANCEL 


UE A sends a CANCEL to IMS A 


{ 


15 


200 OK 


IMS A responds with a 200 OK to UE A 




16 


CANCEL 


IIVIS A forwards the CANCEL to IIVIS B 




17 


200 OK 


IMS B responds with a 200 OK to IMS A 




18 


CANCEL 


IMS B forwards the CANCEL to UE B 


^ 


19 


200 OK 


UE B responds with a 200 OK to IMS B 


\ 


20 












^ 






User B is informed that call has been cancelled 


21 






{ 




^ 






487 Request 
Terminated 


UE_B sends 487 Request Terminated to IMS_B 


\ 


22 


ACK 


IMS_B responds with ACK to UE_B 




23 


487 Request 
Terminated 


IMS B forwards the 487 Request Terminated to 
IMS A 




24 


ACK 


IMS A responds with ACK to IMS B 




25 


487 Request 
Terminated 


IMS A forwards the 487 Request Terminated to 
UE A 




26 


ACK 


UE A responds with ACK to IMS A 




27 




i 














User A is informed that call is terminated 
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4.5.3.1.3.2 



Call CANCEL due to loss of connectivity of calling user during call 



Interoperability Test Description 


Identifier: 


ID IMS 0022 


Summary: 


IMS ends call in case calling UE looses connectivity during a call 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5073 01 


clause 5.2.8.1.2 §1 


Use Case ref.: 


UC_02_I 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B using any user identity 


^^^^^^H ^^^^^^^^H M 


Test Sequence: 


Step 




1 


User B calls User A 


2 


Verify that user A is informed of incoming call of User B 


3 


Verify that user B is informed that UE A is ringing 


4 


User A answers call 


5 


Verify that user B is presented that call in process 


6 


Verify that user A is informed that the call is in progress 


7 


UE_B looses connectivity 


8 


Verify that user A is informed that call has been ended 






Conformance 
Criteria: 


Check 




1 


TP_IMS_5073_01 in CFW step 23 (BYE): 
ensure that { 
when { IMS B receives 'an indication that UE B is no longer available'} 
then { IMS_B sends a BYE to IMS_A 
containing Request_URI 

indicating the Contact_header_value of UE_A and 
containing To_header 

indicating the initial 200_OK_To_value from UE_A 
containing From_header 

indicating the initial INVITE_Fronfi_value from UE_B and 
containing Call-ID_header 

indicating the initial INVITE_Call_ld_value from UE_B and 
containing CSeq_header 

indicating an incremented Sequence_Number and 
containing Route_header 

indicating 'dialog specific routing information for UE_A' and 
'further headers based on local policy or call release reason' 
} 
} 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














13 


















User A answers call 


^ 


14 
















200 OK 


UE_A responds INVITE with 200 OK to indicate 
that the call has been answered 




15 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




16 


200 OK 


IMS B forwards the 200 OK response to UE B 




17 












^ 






User B is presented that call in process 


18 








{ 


^ 






ACK 


UE B acknowledges the receipt of 200 OK for 
INVITE 


\ 


19 


ACK 


IMS B forwards ACK to IMS A 




20 


ACK 


IMS A forwards ACK to UE A 


K 


21 




^ 














User A is informed that the call is in progress 


22 






UE B looses connectivity 


23 






{ 










BYE 


IIVIS B forwards BYE to IIVIS A 




24 


BYE 


IMS A forwards BYE to UE A 




25 




^ 














User A is informed that call has ended 


26 
















200 OK 


UE A sends 200 OK for BYE 




27 


200 OK 


IMS A forwards 200 OK response to IMS B 
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4.5.3.1.3.3 



Call failure due to de-registration of calling user during call 



Interoperability Test Description 


Identifier: 


TD IMS 0023 


Summary: 


IMS ends call in case calling UE is forcefully de-registered in IMS during a call 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5139 01 


clause 5.4.5.1.2 §1 


Use Case ref.: 

^ ' 


UC 02 1 


1^ 

Pre-test 

conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• There is an ongoing dialogue between UE A and UE B 


1 


Test Sequence: 


Step 




1 


User A calls User B 




2 


Verify that user B is informed of incoming call of User A 




3 


Verify that user A is informed that UE B is ringing 




4 


User B answers call 




5 


Verify that User A is informed that call has been answered 




6 


Verify that User B is informed that the call is established 




7 


UE_A is forced to be de-registered in IMS_A 




8 


Verify that user B is informed that call has been ended 


1 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5139_01 in CFW step 23 (BYE): 
ensure that { 
when { IMS_A receives a 'network internal indication that the lifetinfie 
of the last public user identity has expired ' 

} 
then { IMS_A sends a BYE to UE_B 

containing a Request_URI set to Contact_header_value of UE_B and 
containing a To_header set to 

the To_header of the 200_response to initial INVITE and 
containing a From_header set to 

the From_header of the initial INVITE and 
containing a Call-ID_header set to 

the Call-ID_header of the initial INVITE and 
containing a CSeq_header set to 

'CSeq_header from the calling user incremented by one' and 
containing a Route_header set to 

'routeing information towards the called user as stored 

for the dialog' and 
containing 'further headers, based on local policy or the 

requested session release reason' 
} 
} 



ETSI 



91 



ETSI TS 186 011-2 V2.1.1 (2009-02) 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














13 


















User B answers call 


k 


14 








< 


y 






200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 


K 


15 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




16 


200 OK 


IMS A forwards the 200 OK response to UE A 


K 


17 




^ 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 
S-CSCF 




20 


ACK 


IMS B forwards ACK to UE B 




21 












^ 






User B is informed that the call is established 


22 






UE A is forced to be de-registered in IMS A 


23 
















BYE 


IIVIS A forwards BYE to IIVIS B 




24 


BYE 


IMS B forwards BYE to UE B 




25 












^ 






User B is informed that call has ended 


26 










f 






200 OK 


UE B sends 200 OK for BYE 




27 


200 OK 


IMS B forwards 200 OK response to IMS A 
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4.5.3.1.3.4 



Subsequent target refresh request (INVITE) 



Interoperability Test Description 


Identifier: 


TD IMS 0024 


Summary: 


Check that subsequent INVITEs are handled correctly In case of a user initiated call 
hold and resume when home caller puts another home user on hold and resumes call 


1 




Configuration: 


OF INT GALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5106 01 


clause 5.4.3.2 §42 


TP IMS 5121 01 


clause 5.4.3.3 §53 


TP IMS 5121 02 


clause 5.4.3.3 §53 


Use Case ref.: 


UC 03 1 


J 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using INVITE 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B using any user identity 




Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


1^^ 


Verify that user A is informed that call has ended 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5106_01 in GFW step 25A and 40A (INVITE): 
ensure that { 
when { UE_A sends a subsequent INVITE to UE_B } 
then { IMS_B receives the subsequent INVITE 
containing a Record-Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
not containing Route_header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter 
and 

not containing a P -Access-Network-Info header} 
} 


2 


TP_IMS_5121_01 (IMS_B) in GFW step 26A and 41 A (100 Trying): 
ensure that { 
when { UE_B sends a 1xx_response to UE_A } 
then { IMS_A receives the 1xx_response 

containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo header} 
} 


3 


TP_IMS_5121_02 (IMS_B) in GFW step 31 A and 46A (200 OK): 
ensure that { 
when { UE_B sends a 2xx_response to UE_A } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
not containing a access-network-charging-info parameter and 
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Interoperability Test Description 



not containing a P-Access-Network-lnfo_lieader } 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














22A 


















User A puts call on hold 


^ 


23A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 




24A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




25A 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


26A 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




27A 


INVITE 


IMS B forwards INVITE to UE B 


f 


28A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




29A 












^ 






User B is informed that call is on hold 


30A 








{ 


^ 






200 OK 


UE_B responds to INVITE with 200 OK 
indicating media attribute "recvonly" 


\ 


31 A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




32A 


200 OK 


IMS A forwards the 200 OK response to UE A 


K 


33A 




i 














User A is informed that call is on hold 


34A 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




35A 


ACK 


IMS A forwards ACK to IMS B 




36A 


ACK 


IMS B forwards ACK to UE B 




37A 




^ 














User A resumes call 


38A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 




39A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


K 


40A 


INVITE 


IMS A forwards INVITE to IMS B 




41 A 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




42A 


INVITE 


IMS B forwards INVITE to UE B 


• 


43A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




44A 












^ 






User B is informed that call is resumed 


45A 






{ 




{ 






200 OK 


UE_B responds to INVITE with 200 OK 
indicating media attribute "sendrecv" 




46A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




47A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 




48A 




i 














User A is informed that call is resumed 



ETS\ 



94 



ETSI TS 186 011-2 V2.1.1 (2009-02) 



4.5.3.1.3.5 



Subsequent target refresh request UPDATE) 



Interoperability Test Description 


Identifier: 


TD IMS 0025 


Summary: 


Check that subsequent UPDATES are handled correctly In case of a user initiated call 
hold and resume when home caller puts another home user on hold and resumes call 


Configuration: 


OF INT CALL 


SUT 


IMS_A, IMS_B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5106 02 


clause 5.4.3.2 §42 


TP IMS 5121 02 


clause 5.4.3.3 §53 


Use Case ref.: 


UC 03 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using UPDATE 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B using any user identity 




Test Sequence: 


Step 


J 


1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 






Conformance 
Criteria: 


Check 




1 


TP_IMS_5106_02 (IMS_A) in CFW step 24A and 33A (UPDATE): 
ensure that { 
when { UE A sends an UPDATE to UE B } 
then { IMS_B receives the UPDATE 

containing a Record-Route_header 

containing the S-CSCF_SIP_URI of IMS_A and 
not containing Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
not containing a access-network-charging-info_parameter 
and 

not containing a P-Access-Network-lnfo header} 
} 


2 


TP_IMS_5121_02 (IMS_B) in CFW step 28A and 37A (200 OK): 
ensure that { 
when { UE_B sends a 2xx_response to UE_A } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo header} 
} 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














22A 


















User A puts call on hold 


^ 


23A 
















UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 




24A 


UPDATE 


IIVIS A forwards UPDATE to IIVIS B 




25A 


UPDATE 


IMS B forwards UPDATE to UE B 




26A 












^ 






User B is informed that call is on hold 


27A 








< 


y 






200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 


K 


28A 


200 OK 


ll\/IS_B forwards 200 OK response to \MS_A 




29A 


200 OK 


IMS A P-CSCF forwards the 200 OK response 
toUE A 




30A 




i 














User A is informed that call is on hold 


31A 






User A resumes call 


^ 


32A 
















UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 




33A 


UPDATE 


IIVIS A forwards UPDATE to IMS B 




34A 


UPDATE 


IMS B forwards UPDATE to UE B 




35A 












^ 






User B is informed that call is resumed 


36A 








< 


y 






200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 


K 


37A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




38A 


200 OK 


IMS A forwards the 200 OK response to UE A 


K 


39A 




i 














User A is informed that call is resumed 
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4.5.3.1.4 



Subsequent Request Procedures - Terminating Network 



Interoperability Test Description 


Identifier: 


TD IMS 026 


Summary: 


IMS ends call in case called UE looses connectivity during a call 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5074 01 


clause 5.2.8.1.2 §11 


Use Case ref.: 


UC 02 1 


I^^^^^^^^^^^^^l 







Pre-test 
conditions: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B has IP bearers established to their respective IMS networks as 

per clause 4.2.1 

UE_A is registered in IMS_A using any user identity 

UE_B is registered in IMS_B using any user identity 



Test Sequence: 



Step 



User A calls User B 



Verify that user B is informed of incoming call of user A 



Verify that user A is informed that UE_B is ringing 



User B answers call 



Verify that User A is informed that call has been answered 



Verify that User B is informed that the call is established 



UEB looses connectivity 



Verify that user A is informed that call has been ended 



Conformance 
Criteria: 



Check 




TP_IMS_5074_01 in GFW step 23 (BYE): 
ensure that { 
when { IMS_B receives 'an indication that UE_B is no_ionger_avaiiabie' } 
then { IMS_B sends a BYE to IMS_A 
containing Request_URI 

indicating the Contact_header_vaiue of UE_A and 
containing To_header 

indicating the initial INVITE_To_value from UE_A 
containing From_header 

indicating the initial 200_OK_From_value from UE_B and 
containing Call-ID_header 

indicating the initial lNVlTE_Call_ld_value from UE_A and 
containing CSeq_header 

indicating an incremented Sequence_Number and 
containing Route_header 

indicating 'dialog specific routing information for UE_A' and 
'further headers based on local policy or call release reason' 



L 



} 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














13 


















User B answers call 


k 


14 








{ 


^ 






200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 


\ 


15 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




16 


200 OK 


IMS A forwards the 200 OK response to UE A 


K 


17 




^ 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 




20 


ACK 


IMS B forwards ACK to UE B 




21 












^ 






User B is informed that the call is established 


22 






UE B looses connectivity 


23 






{ 










BYE 


IIVIS B sends a BYE to IIVIS A 




24 


BYE 


IMS_A forwards the BYE response to UE_A 




25 




i 














UE A is informed that call has ended 


26 
















200 OK 


UE A responds to the BYE with 200 OK 




27 


200 OK 


IMS A forwards the 200 OK response to IMS B 
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4.5.3.1.5 



Dialogue Procedures - Topology Hiding 



4.5.3.1.5.1 



Normal call 



Interoperability Test Description 


Identifier: 


ID IMS 0027 


Summary: 


Basic call with topology hiding 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5135 01 


clause 5.10.4.1 §7 


TP IMS 5137 01 


clause 5.10.4.2 §1 


TP IMS 5404 01 


clause 5.10.2.2 §1 


TP IMS 5408 01 


clause 5.10.2.3 §1 


TP IMS 5408 03 


clause 5.10.2.3 §1 


TP IMS 5414 01 


clause 5.10.3.2 §1 


TP IMS 5137 02 


clause 5.10.4.2 §1 


TP IMS 5137 03 


clause 5.10.4.2 §1 


Use Case ref.i 


UC 02 1 


^^^^L ^^^^^^^^Hl 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• IMS A is configured for topology hiding 




Test Sequence: 


Step 




1 


User A calls user B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers the call 


5 


Verify that user A is informed that call has been answered 


6 


User B is informed that the call is established 


7 


User A ends the call 


8 


Verify with UE B that call has been released 


9 


Verify with UE_A that call has been released 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5135_01 in GFW step 4 (INVITE): 
ensure that { 
when { UE B sends a initial INVITE to IMS A } 
then { IMS_A sends the initial INVITE to IMS_B 

containing an additional topmost Record-Route header 
indicating the IBCF SIP URI of IMS A} 
} 


2 


TP_IMS_5137_01 in GFW step 4 (INVITE): 
ensure that { 
when { UE A sends an initial INVITE to UE Bj 
then { IMS_A sends the INVITE to IMS_B 
containing a Via_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Record- Route_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by parameter) } 

} 
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Interoperability Test Description 



TP_IMS_5404_01 in CFW step 4 (INVITE): 
ensure that { 
when { UE_A sends an initial INVITE to UE_B 

containing a P-Charging-Vector_header and 
containing a P-Charging-Function-Addresses_header} 
then { IMS_A sends the INVITE 

not containing (a P-Charging-Vector_header and 

a P-Charging-Function-Addresses_header) } 

L 



TP_IMS_5408_01 in CFW step 19 (ACK): 
ensure that { 
when { UE_A sends an ACK to UE_B } 
then { IMS_A sends the ACK to IMS_B 
containing a Via_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) } 

L 



TP_IMS_5408_03 in CFW step 24A (BYE): 
ensure that { 
when { UE_A sends a BYE to UE_B } 
then { IMS_A sends the BYE to IMS_B 
containing a Via_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Record- Route_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) } 
1 



TP_IMS_5414_01 in CFW step 5 (100 Trying): 
ensure that { 

when { UE_A sends an initial INVITE to UE_B and 
IMS_A sends the INVITE to IMS_B } 

then { IMS_B sends a 100_response to IMS_A } 
L 



TP_IMS_5137_02 in CFW step 10 (180 Ringing): 
ensure that { 
when { UE_B sends a 1xx_response to UE_A } 
then { IMS_B sends the 1xx_response to IMS_A 
containing Via_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing Record-Route_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) } 

L 



TP_IMS_5137_03in CFW step 15and28A (200 OK): 
ensure that { 
when { UE_B sends a 2xx_response to UE_A } 
then { IMS_B sends the 2xx_response to IMS_A 
containing a Via_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Record- Route_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) } 

1 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














1 


















User A calls User B 


^ 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 




3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


5 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




6 


INVITE 


IMS B forwards INVITE to UE B 


f 


7 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




8 












^ 






User B is informed of incoming call of User A 


9 






/^ 


f 


^ 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 


\ 


10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 




12 




i 














User A is informed that UE B is ringing 


13 






User B answers call 


k 


14 








f 


• 






200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




15 


200 OK 


IMS B forwards 200 OK response to IMS A 




16 


200 OK 


IMS A forwards the 200 OK response to UE A 




17 




i 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 




20 


ACK 


IMS B forwards ACK to UE B 




21 












^ 






User B is informed that the call is established 


22A 






User A ends call 


^ 


23A 
















BYE 


UE A releases the call with BYE 




24A 


BYE 


IMS A forwards BYE to IMS B 




25A 


BYE 


IMS B forwards BYE to UE B 




26A 












^ 






User B is informed that call has ended 


27A 






f 


{ 


^ 






200 OK 


UE B sends 200 OK for BYE 


\ 


28A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




29A 


200 OK 


IMS A forwards the 200 OK response to UE A 




30A 




i 














User A is informed that call has ended 
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4.5.3.1.5.2 



CANCEL call by calling user 



Interoperability Test Description 


Identifier: 


ID IMS 0028 


Configuration: 


CF INT CALL 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5408 02 


clause 5.10.2.3 §1 


Use Case ref.: 


UC 02 1 


Summary: 


Calling user cancels call before its establishment with topology hiding 




Pre-test 


• HSS of IMS_A and of IMS B is configured according to table 1 




conditions: 


• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• IMS A is configured for topology hiding 




1^^^^" 




I 


Test Sequence: 


Step 


J 


1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User A cancels call 


5 


Verify that user B is informed that call has been cancelled 


^^^^ 


Verify that user A is informed that call is terminated 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5408_02 in CFW step 16 (CANCEL): 








ensure that { 








when { UE A sends a CANCEL to UE B } 








then { IMS_A sends the CANCEL to IMS_B 








containing a Via_header 








containing (encrypted_consecutive_header_entries and 








a tokenized-by_parameter) and 








containing a Record- Route_header 








containing (encrypted_consecutive_header_entries and 








a tol<enized-by_parameter) and 








containing a Route_header 








containing (encrypted_consecutive_header_entries and 








a tokenized-by parameter) } 
} 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


u 

s 
e 
r 
B 






1 


















1 Iqpt a ppiIIq I Iqpt R 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 




3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B 


f 


7 

Q 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




O 

9 






/^ 


f 


^ 






180 Ringing 


user b IS inTormeo ot incoming can ot user a 
UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 


\ 


10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 




12 
13 




i 














User A is informed that UE B is ringing 
User A cancels the call 


^ 


14 
















CANCEL 


UE A sends a CANCEL to IMS A 


{ 


15 


200 OK 


IMS A responds with 200 OK to UE A 




16 


CANCEL 


IIVIS A forwards the CANCEL to IIVIS B 




17 


200 OK 


IMS B responds with 200 OK to IMS A 




18 


CANCEL 


IMS B forwards the CANCEL to UE B 


^ 


19 


200 OK 


UE B responds with 200 OK to IMS B 


\ 


20 












^ 






User B is informed that call has been cancelled 


21 






{ 




^ 






487 Request 
Terminated 


UE_B sends 487 Request Terminated to IMS_B 


\ 


22 


ACK 


IMS_B responds with ACK to UE_B 




23 


487 Request 
Terminated 


IMS B forwards the 487 Request Terminated to 
IMS A 




24 


ACK 


IMS A responds with ACK to IMS B 




25 


487 Request 
Terminated 


IMS A forwards the 487 Request Terminated to 
UE A 




26 


ACK 


UE A responds with ACK to IMS A 




27 


















User A is informed that call is terminated 


i 
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4.5.3.1.5.3 



Normal call with hold/resume 



Interoperability Test Description 


Identifier: 


TD IMS 0029 


Summary: 


User initiated call hold and resume when a home caller puts a roaming user on hold 
and resumes call with topology hiding 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5408 04 


clause 5.10.2.3 §1 


Use Case ref.: 


UG 03 R 


^^^^^^^^^1 


^i— M 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using INVITE 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered via IMS A in IMS_B using any user identity 

• IMS A is configured for topology hiding 


^^^^ 1 


■ 


Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 


I 


Conformance 
Criteria: 


Check 


J 


1 


TP_IMS_5408_04 in GFW step 38A and 57A (INVITE): 
ensure that { 
when {UE A sends a subsequent INVITE to UE Bj 
then { IMS_A sends the INVITE to IMS_B 
containing a Via_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Record- Route_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 

containing (encrypted_consecutive_header_entries and 
a tokenized-by parameter) } 

} 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


u 

s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 














34 


















User B is presented that call is in progress 


i 


35A 






User A puts call on hold 


^ 


36A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 








37A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 






y 


38A 


INVITE 


IMS A forwards INVITE to IMS B 


{ 


39A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




40A 


INVITE 


IMS B forwards INVITE to IMS A 


\ 


41A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




42A 


INVITE 


IMS A forwards INVITE to UE B 




43A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




44A 








i 










User B is informed that call is on hold 


45A 






< 










200 OK 


UE_B responds to INVITE with 200 OK 
indicating media attribute "recvonly" 




46A 


200 OK 


IMS A forwards 200 OK response to IMS B 




47A 


200 OK 


IMS B forwards 200 OK response to IMS A 




48A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








49A 


ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 






{ 


50A 


ACK 


IMS A forwards ACK to IMS B 




51A 


ACK 


IMS B forwards ACK to IMS A 




52A 


ACK 


IMS A forwards ACK to UE B 




53A 




i 














User A is informed that call is on hold 


54A 






User A resumes call 


— > 


55A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 


/^ 






56A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 






y 


57A 


INVITE 


IMS A forwards INVITE to IMS B 




58A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




59A 


INVITE 


IMS B forwards INVITE to IMS A 




60A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




61A 


INVITE 


IMS A forwards INVITE to UE B 


\ 


62A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




63A 








i 










User B is informed that call is resumed 
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4.5.4 Messaging 



4.5.4.1 



Messaging with SIP URI public identities 



Interoperability Test Description 


Identifier: 


ID IMS 0031 


Summary: 


Ensure that messaging works with SIP identity without topology hiding 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5097 05 


clause 5.4.3.2 §1 


TP IMS 5097 06 


clause 5.4.3.2 §1 


TP IMS 5117 02 


clause 5.4.3.3 §44 


TP IMS 5118 01 


clause 5.4.3.3 §45 


Use Case ref.: 


UC 05 1 




Pre-test 


• HSS of IMS_A and of IMS B is configured according to table 1 


conditions: 


• UE_A and UE_B have IP bearers established to their respective IMS networks as 




per clause 4.2.1 




• UE_A is registered in IMS_A using user2 according to table 1 




• UE_B is registered in IMS_B using any user identity 




• IMS A is within the trust domain of IMS B 




• UE_A and UE_B registered with SIP URI public identities 




• IMS A not configured for topology hiding 


1^^^^^^^^^^ 




Test Sequence: 


Step 




1 


User A sends message to user B 


2 

I 


Verify that user B receives message from user A 


Conformance 
Criteria: 


m 

Check 




1 


TP_IMS_5097_05 in GFW step 3 (MESSAGE) 






ensure that { 






when { UE_A sends a MESSAGE to UE_B } 






then { IMS_B receives the MESSAGE 






not containing a Route header 






indicating the S-CSCF_SIP_URI of IMS_A 






containing a P-Charging-Vector_header 






(containing an icid_parameter and 






containing a orig-ioi_parameter indicating IMS_A and 






not containing a term-ioi_parameter) and 






containing a Record-Route_header 






indicating the originating S-CSCF_SIP_URI and 






containing a P-Charging-Vector_header 






not containing a access-networl<-charging-info_parameter and 






not containing a P-Access-Network-lnfo header} 
} 


2 


TP_IMS_5097_06 in GFW step 3 (MESSAGE) 






ensure that { 






when { UE_A sends a MESSAGE to UE_B 






not containing a P-Preferred-ldentity_header or 






containing a P-Preferred-ldentity_header 






not indicating a Tei_URI } 






then { IMS_B receives the MESSAGE 






containing a P-Asserted-ldentity_header 






indicating the default_registered_public_identity and 






containing a P-Asserted-ldentity_header 






indicating a Tel URI} 
} 


3 


TP_IMS_51 17_02 in GFW step 7 (200 OK) 






ensure that { 






when { UE_B sends a 2xx_response to UE_A } 






then { IMS_A receives the 2xx_response 






containing a P-Charging-Vector_header 






not containing a access-network-charging-info_parameter and 






not containing a P-Access-Network-lnfo header} 
} 
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Interoperability Test Description 



TP_IMS_5118_01 in CFW step 7 (200 OK) 
ensure that { 
when { UE_B sends 200_response to UE_A } 
then { IMS_A receives the 200_response 

containing a P-Charging-Vector_header 
containing a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operatorjdentifier of IMS_B } 
1 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














1 


















User A sends an instant message to user B 


^ 


2 
















MESSAGE 


UE A sends MESSAGE to IMS A 




3 


MESSAGE 


IMS A sends MESSAGE to IMS B 




4 


MESSAGE 


IMS B sends MESSAGE to UE B 




5 












^ 






User B is informed about the instant message 


6 








/^ 


y 






200 OK 


UE B sends 200 OK to IMS B 




7 


200 OK 


IMS B sends 200 OK to IMS A 




8 


200 OK 


IMS A sends 200 OK to UE A 


K 


9 




i 














Optional: User A is presented a delivery report 
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4.5.4.2 



Messaging with TEL URI identities 



Interoperability Test Description 


Identifier: 


TD IMS 0032 


Summary: 


Ensure that messaging works with TEL URI identities 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5097 07 


clause 5.4.3.2 §1 


TP IMS 5117 02 


clause 5.4.3.3 §44 


TP IMS 5118 01 


clause 5.4.3.3 §45 


TP IMS 5117 06 


clause 5.4.3.3 §44 


Use Case ref.: 


UC 05 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A is registered in IMS_A using userS according to table 1 

• UE_B is registered in IMS_B using userS according to table 1 

• IMS A is within the trust domain of IMS B 


I^^^^^^^^H 


^V 1 


Test Sequence: 


step 


J 


1 


User A sends message to User B 


2 


Verify that user B receives message from user A 




Conformance 
Criteria: 


Check 




J 


1 


TP_IMS_5097_07 in GFW step 3 (MESSAGE) 
ensure that { 
when { UE_A sends a MESSAGE to UE_B 

not containing a P- Preferred- lclentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI } 
then { IMS_B receives the MESSAGE 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel derived SIP URI } 
} 


2 


TP_IMS_51 17_02 in GFW step 7 (200 OK) 
ensure that { 
when { UE_B sends a 2xx_response to UE_A } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo header} 
} 


3 


TP_IMS_51 18_01 in GFW step 7 (200 OK) 
ensure that { 
when { UE_B sends 200_response to UE_A } 
then { IMS_A receives the 200_response 

containing a P-Charging-Vector_header 
containing a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS Bj 
} 
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Interoperability Test Description 



TP_IMS_5117_06 in CFW step 7 (200 OK) 
ensure that { 
when { UE_B sends a 2xx_response to UE_A 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating aTel_URI } 
then { ll\/IS_A receives the 2xx_response 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel_derived_SIP_URI } 
} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














1 


















User A sends an instant message to user B 


^ 


2 
















MESSAGE 


UE A sends MESSAGE to IMS A 




3 


MESSAGE 


IMS A sends MESSAGE to IMS B 




4 


MESSAGE 


IMS B sends MESSAGE to UE B 




5 












^ 






User B is informed about the instant message 


6 








< 


y 






200 OK 


UE B sends 200 OK to IMS B 




7 


200 OK 


IMS B sends 200 OK to IMS A 




8 


200 OK 


IMS A sends 200 OK to UE A 


K 


9 




i 














Optional: User A is presented a delivery report 
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4.5.4.3 



Messaging with DNS/ENUM lookup procedure 



Interoperability Test Description 


Identifier: 


TD IMS 0033 


Summary: 


Ensure that messaging works with DNS/ENUIVI lookup procedure 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5097 08 


clause 5.4.3.2 §1 


IP IMS 5117 04 


clause 5.4.3.3 §44 


Use Case ref.i 


UC 05 1 






Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using user3 according to table 1 

• IMS_A is within the trust domain of IMS_B 

• DNS B is configured with a DNS/ENUM entry mapping 




Test Sequence: 


Step 


i 


1 


User A sends message to user B's Tel URI 


2 


Verify that user B receives message from user A 


" 




Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_08 in GFW step 5 (MESSAGE) 
ensure that { 
when { UE_A sends a MESSAGE to UE_B 
containing a Request_URI 
indicating a Tel_URI } 
then { IMS_A sends a DNS_Query to DNS_B 

containing the Tei_URI_E. 164_Number} 
when { IMS_A receives DNS_Response 

containing a NAPTR_Resource_Record 
indicating the SIP URI of UE Bj 
then { IMS_A sends the MESSAGE to IMS_B 
containing a Request_URI 

indicating a SIP_URI 
containing a P-Charging-Vector_header 
not containing a access-network-charging-info parameter} 
} 


2 


TP_IMS_51 17_04 in CFW step 9 (200 OK) 
ensure that { 
when { UE_B sends a 2xx_response to UE_A 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
not indicating a Tel_URI} 
then { IMS_A receives the 2xx_response 

containing a P- Asserted- ldentity_header 

indicating the default_registered_public_identity and 
containing a P- Asserted- ldentity_header 
indicating a Tel URI } 
} 
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Step 


Direction 


IVIessage 


Comment 
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r 
A 
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A 
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S 
A 
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S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 














1 




















User A sends an instant message 


^ 


2 


















MESSAGE 


UE A sends MESSAGE to IMS A 




3 


DNS QUERY 


IMS A sends DNS QUERY to DNS A containing 
E.164TELURI 




4 


DNS 
RESPONSE 


DNS_A sends DNS RESPONSE containing 
NAPTR resource record to IMS A 




5 


IVIESSAGE 


IMS_A sends MESSAGE to IMS_B containing 
Request URI which indicates a SIP URI 






6 


MESSAGE 


IMS B sends MESSAGE to UE B 


7 














^ 






User B is informed about the instant message 


8 






/ 


f 




( 






200 OK 


UE B sends 200 OK to IMS B 




9 


200 OK 


IMS B sends 200 OK to IMS A 






10 


200 OK 


IMS A sends 200 OK to UE A 




11 




d 
















Optional: User A is presented a delivery report 
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4.5.4.4 



Messaging when roaming 



Interoperability Test Description 


Identifier: 


ID IMS 0034 


Summary: 


Ensure that messaging works while roaming 


Configuration: 


CF ROAM CALL 


SUT 


IMS AandlMS B 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5108 02 


clause 5.4.3.3 §1 


IP IMS 5118 01 


clause 5.4.3.3 §45 


IP IMS 5050 01 


clause 5.2.6.3 §46 


Use Case ref.: 


UG 05 R 


1^^^ 


Pre-test 


• HSS of IMS_A and of IMS B is configured according to table 1 


conditions: 


• UE_A and UE_B have IP bearers established to their respective IMS networks as 




per clause 4.2.1 




• UE_A is registered in IMS_A using any user identity 




• UE B is registered in IMS B via IMS A using any user identity 




^ 


Test Sequence: 


Step 




1 


User A sends message to user B 


2 


Verify that user B receives message from user A 




Conformance 
Criteria: 


Check 


J 


1 


TP_IMS_5108_02 in CFW step 4 (MESSAGE) 






ensure that { 






when { UE A sends a MESSAGE to UE B 






IMS A sends the MESSAGE to IMS B 






containing a P-Charging-Vector_header 






containing an icid parameter} 






then { IMS_B sends the MESSAGE to UE_B 






containing no Route header and 






indicating the S-CSCF_SIP_URI of IMS_B and 






containing a P-Charging-Vector_header 






containing the same icid_parameter and 






not containing ioi_parameters 






containing a Record-Route header 






containing the S-CSCF SIP URI of IMS B} 
} 


2 


TP_IMS_51 18_01 in CFW step 9 (200 OK) 






ensure that { 






when { UE_B sends 200_response to UE_A } 






then { IMS_A receives the 200_response 






containing a P-Charging-Vector_header 






containing a orig-ioi_parameter 






indicating operatorjdentifier of IMS_A and 






containing a term-ioi_parameter 






indicating operator identifier of IMS Bj 
} 


3 


TP_IMS_5050_01 in CFW step 3 (MESSAGE) 






ensure that { 






when { IMS A receives a MESSAGE from UE Bj 






then { IMS_A sends the MESSAGE to IMS_B 






containing a Route_header 






indicating the 'list of Service Route header URIs 






from registration' and 






not containing a P-Preferred-ldentity_header and 






containing P-Asserted-ldentity_header 






containing an address of UE_A and 






containing the P-Charging-Vector_header 






containing an icid parameter} 
} 
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Step 


Direction 


IVIessage 


Comment 




U 
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A 
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r 
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E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 














1 


















User A sends an instant message to user B 


^ 


2 
















MESSAGE 


UE A sends MESSAGE to IMS A 






y 


3 


IVIESSAGE 


IMS A sends MESSAGE to IMS B 


< 


4 


MESSAGE 


IMS B sends MESSAGE to IMS A 




5 


MESSAGE 


IMS A sends MESSAGE to UE B 


K 


6 


















User B is informed about the instant message 


7 
















200 OK 


UE B sends 200 OK to IMS A 




8 


200 OK 


IMS A sends 200 OK to IMS B 


< 


9 


200 OK 


IMS B sends 200 OK to IMS A 




10 


200 OK 


IMS A sends 200 OK to UE A 


K 






11 




i 














Optional: User A is presented a delivery report 



4.5.4.5 



Messaging with receiving user not registered 



Interoperability Test Description 


Identifier: 


ID IMS 0035 


Summary: 


Standalone message procedure with receiving user not registered 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5114 02 


clause 5.4.3.3 §34 


Use Case ref.: 


UC 05 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is /7of registered in IMS_B 

• IMS_B is nof configured with any filter criteria to contact 'any AS' 


1 


Test Sequence: 


Step 


J 


1 


User A sends message to a valid user B identity 


2 


Verify that user A is informed that user B could not be reached 


^^^^ 






Conformance 
Criteria: 


Check 


J 


1 


TP_IMS_51 14_02 in GFW step 5 (4xx Response) 
ensure that { 
when { UE A sends a MESSAGE to UE B and 

IMS_A sends the MESSAGE to IMS_B } 
then { IMS B sends a 4xx response to IMS A 
} 
} 
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Step 


Direction 


IVIessage 


Comment 




U 
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r 
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A 
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S 
A 


\ 
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B 


U 
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B 


U 
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r 
B 














1 


















User A sends an instant message to NON 
registered user B 


^ 




2 
















MESSAGE 


UE A sends MESSAGE to IMS A 




3 


MESSAGE 


IMS A sends MESSAGE to IMS B 




4 


















IMS B detects that user B is not registered 


5 






{ 


{ 








4xx 
Response 


ll\/IS_B sends 4xx Response to ll\/IS_A 




6 


4xx 
Response 


IMS_A sends 4xx Response to UE_A 




7 


















User A is informed that user B could not be 
reached 


^ 





















4.5.4.6 



Messaging with receiving user barred 



Interoperability Test Description 


Identifier: 


TD IMS 0036 


Summary: 


Ensure that messaging works when receiving user has been barred 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


TP IMS 5097 12 


clause 5.4.3.2 §1 


Use Case ref.: 


UC 05 1 


__ 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• User B is barred in IMS B 


as 


^ — -^^ 1 


Test Sequence: 


Step 


J 


1 


User A sends message to User B 


2 


Verify that user A is informed that user B could not be reached 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_12 in CFW step 5 (403 Response) 
ensure that { 
when { UE A sends a MESSAGE to UE B and 
IMS_A sends the MESSAGE to IMS_B 
containing a P-Asserted-ldentity_header 
indicating a barred_user in IMS_B } 
then { IMS B sends 403 response to IMS A } 
} 
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Step 


Direction 


IVIessage 


Comment 
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B 














1 


















User A sends an instant message to registered 
user B 


^ 




2 
















MESSAGE 


UE A sends MESSAGE to IMS A 




3 


MESSAGE 


IMS A sends MESSAGE to IMS B 




4 


















IMS B detects that user B has been barred 


5 






< 


< 








403 
Response 


ll\/IS_B sends 403 Response to ll\/IS_A 




6 


403 
Response 


IMS_A sends 403 Response to UE_A 




7 


















Optional: User A is informed that user B could 
not be reached 


i 
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4.5.5 Supplementary Services 



4.5.5.1 



Supplementary Service HOLD with AS 



Interoperability Test Description 


Identifier: 


ID IMS 0030 


Summary: 


Ensure that IMS supports properly application services based on the HOLD 
supplementary service 


Configuration: 


OF ROAM AS 


SUT 


IMS B 


References 


Test Purpose 


Spec. Ref. 


IP IMS 5310 01 


clause 5.4.6.1.2 §1 


IP IMS 5302 01 


clause 5.4.3.3 §53 


IP IMS 5312 01 


clause 5.4.6.1.3 §1 


Use Case ref.: 


UG 10 R 




Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B via IMS_A using any user identity 

• AS B is configured to contact AS B in case of HOLD activation 




Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User B puts call on hold 


8 


Verify that user A is informed that call on hold with AS tone and/or 
announcement 


9 


Verify that user B is informed that call on hold 


10 


User B resumes call 


11 


Verify that user A is informed that call is resumed 


12 


Verify that user B is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 




Conformance 
Criteria: 


Check 


J 


1 


TP_IMS_5310_01 in CFW step 30 and Step 32 (INVITE) 
ensure that { 
when { IMS_A sends a subsequent INVITE to IMS_B 
containing a P-Charging-Vector_header 
containing an access-network-charging-info_parameter and 
containing a P-Access-Network-lnfo header 

} 
then { IMS_B sends the INVITE to AS_B 

containing a P-Charging-Vector_header 
containing an access-network-charging-info_parameter and 
containing a P-Access-Network-lnfo header 
} 
} 




2 


TP_IMS_5302_01 in CFW step 41 and Step 43 (2XX) 
ensure that { 

when { IMS B receives a 2xx response from UE B 
}S 
then { IMS_B sends the 2xx_response to AS_B 
containing a P-Charging-Vector_header 

containing an access-network-charging-info_parameter and 
containing a P-Access-Network-lnfo header 
} 
} 
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Interoperability Test Description 



TP_IMS_5312_01 in CFW step 41 and Step 43 (200 OK) 
ensure that { 
when { IMS_B receives a 200_response from UE_B 
containing a P-Charging-Vector_header 

containing an access-network-charging-info_parameter 

} 

then { IMS_B sends the 200_response to AS_B 
containing a P-Charging-Vector_header 

containing a access-network-charging-info_parameter 
} 
1 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


u 

s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 








1 






28 




















User B puts call on hold 


^ 




28 






/^ 












INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 


< 


29 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




30 


INVITE 


IMS_A forwards INVITE to IMS_B 


y 


31 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


y 


32 


INVITE 


IMS_B sends relNVITE to AS_B 


y 


33 


100 Trying 


AS_B optionally responds with a 100 Trying 
provisional response 


f 


35 


INVITE 


AS_B sends relNVITE to IMS_B 




35 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




36 


INVITE 


IMS_B forwards relNVITE to IMS_A 




37 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




38 


INVITE 


IMS_A forwards relNVITE to UE_A 








39 


100 Trying 


UE _A optionally responds with a 100 Trying 
provisional response 








40 




/^ 
















User A is informed that call is on hold (with tone 
and/or announcement) 




41 


















200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 






< 


42 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


y 


43 


200 OK 


IMS_B forwards 200 OK response to AS_B 


y 


44 


200 OK 


AS_B forwards 200 OK response to IMS_B 




45 


200 OK 


IMS_B forwards 200 OK response to IMS_A 


K 


46 


200 OK 


IMS_A forward the 200 OK to UE_B 




47 




















User B is informed that the call is on hold 


k 


48 


















ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 




49 


ACK 


IMS_A forwards ACK to IMS_B 




50 


ACK 


IMS_B forwards ACK to AS_B 

























ETS\ 



117 



ETSI TS 186 011-2 V2.1.1 (2009-02) 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


u 

s 
e 
r 
B 


U 

E 
B 


1 

IVI 
S 
A 


1 
IVI 

s 

B 


A 
S 
B 






51 










y 


• 


f 




ACK 


AS_B forwards ACK to IMS_B 




52 


ACK 


IMS_B forwards ACK to IMS_A 




53 


ACK 


IMS_A forwards ACK to UE_B 


\ 


54 




















User B resumes call 


^ 




55 






y 












INVITE 


UE_B sends second relNVITE message 
indicating media attribute "sendrecv" (Call 
Resume) 


y 


56 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


\ 


57 


INVITE 


IMS_A sends relNVITE to IMS_B 


{ 


58 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


f 


59 


INVITE 


IMS_B sends relNVITE to AS_B 


y 


60 


100 Trying 


AS_B optionally responds with a 100 Trying 
provisional response 


\ 

• 


61 


INVITE 


AS_B forwards INVITE to IMS_B 




62 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




63 


INVITE 


IMS_B sends relNVITE to IMS_A 




64 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




65 


INVITE 


IMS_A forwards relNVITE to UE_A 








66 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








67 




















User A is informed that call is resumed 


i 




68 


















200 OK 


UE_A sends the 200 OK indicating media 
attribute "sendrecv" to IMS A 






y 


69 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


• 


70 


200 OK 


IMS_B forwards 200 OK response to AS_B 


{ 


71 


200 OK 


AS_B forwards the 200 OK for INVITE 




72 


200 OK 


IMS_B forwards 200 OK to IMS_A 




73 


200 OK 


IMS_A forwards 200 OK to UE_B 


\ 


74 




















User B is informed that call is resumed 


k 




75 






{ 












ACK 


UE_B sends ACK to IMS_A 




76 


ACK 


IMS_A forwards ACK to IMS_B 


f 


77 


ACK 


IMS_B forwards ACK to AS_B 


• 


78 


ACK 


AS_B forwards ACK to IMS_B 




79 


ACK 


IMS_B forwards ACK to IMS_A 




80 


ACK 


IMS_A forwards ACK to UE_A 








81 


















ACK 


User A is informed that call resumed 


i 
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